Re: AW: Problem with GUPnP root device / Question regarding GUPnP deinitialization

[Jens Georg <mail jensge org>]

On Di, 2011-06-28 at 19:39 +0200, Alexander Kirschner wrote:
> Hi Jens,
> 
> thank you for your quick reply! I read about your project dealing with combining Qt and GUPnP. What is your experience on that matter?

I had to stop due to some problems with bindability which are now
resolving slowly, the last major trouble-spot I'm seeing is the
ResourceFactory since it is very GObject/GType centric.

Also hopefully at some point Richard Dale's introspection-based Qt
bridge for GObject libraries will be usable...

> 
> Yes, we are actually combining GUPnP and Qt... in Qt 4.7.1 there is still an issue that the GUPnP context is running in the Qt main thread (no other thread can be assigned); but this seems not to be a problem for now (and will apparently be fixed in Qt 4.8... are you involved in this?).

I'm kind of involved, but for reasons not related to GUPnP at all. I
suspect you mean http://bugreports.qt.nokia.com/browse/QTBUG-14425 ?

That wouldn't really help you with current GUPnP versions, they need to
be associated with a context anyway, so you would need to pass
g_main_context_get_thread_default() manually. We are working on a series
of patches that deprecates the explicit main_context and uses
g_main_context_get_thread_default() instead. So with Qt 4.8 and the
upcoming development release it should finally work OOTB.

> 
> By "deinitializing/initializing" GUPnP I meant shutting down and restarting UPnP root device and control point without shutting down our enclosing Qt application. We simply weren't sure if calling "g_object_unref" with main context as param is sufficient and also unregisters the signal handlers.

Well it depends. GObjects are reference-counted. So if you call
g_object_unref and it had a reference count of 1, the object will be
destroyed and all signal handlers disconnected. If it was >1, only the
reference count will be decreased and all signal handlers stay. Think of
QSharedPointer, with the difference that it works ;)

For temporarily disabling a context (which then disables all associated
devices/controlpoints etc.) I'd suggest to use g_object_set
(control_point or context, "active", FALSE, NULL);


> We reran some tests using valgrind... nothing suspicious. Using valgrind with --leak-check=full (as always) leads to a lot of leak-hints including libsoup, but we don't think the problem is related to these leaks. The funny thing is that running our tests within valgrind enhances our stability dramatically (no crashes so far).

So most likely it's a race condition. Is your project open source?

> 
> Besides the trace I already mentioned in my last email we often get this error...
> 
> (<unknown>:8573): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GUPnPDeviceInfo'
> ** (<unknown>:8573): CRITICAL **: gupnp_device_info_get_udn: assertion `GUPNP_IS_DEVICE_INFO (info)' failed
> 
> ... any suggestions?

No, not really. I suspect there's something fishy going on inside your
code, like you missed to initialize something.