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

[Alexander Kirschner <alexander kirschner jambit com>]

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?

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?).

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.

The last couple of hours we did some testing with GUPnP 0.16.1 and GSSDP 0.10.0. Our problems are definetely not solved by upgrading to the newer versions.

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).

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?


Thanks & Best regards,

Alex

-- 
Alexander Kirschner M.Sc., Software Architect
Phone: +49.89.45 23 47-232
PGP-Fingerprint: 98EC 0735 04F7 3FF5 E8F3  E5B1 B836 D6D0 C5B1 5BEA


-----Ursprüngliche Nachricht-----
Von: Jens Georg [mailto:mail jensge org] 
Gesendet: Dienstag, 28. Juni 2011 12:58
An: Alexander Kirschner
Cc: gupnp-list gnome org
Betreff: Re: Problem with GUPnP root device / Question regarding GUPnP deinitialization

On Di, 2011-06-28 at 11:28 +0200, Alexander Kirschner wrote:
> Hi all,
> 
>  
> 
> we are implementing a software tool using GUPnP 0.14.1-1. Our software
> contains a UPnP control point as well as a UPnP root device and is
> based on Qt 4.7.1. Right now we are facing two major issues...

Nice to hear that you opted to use GUPnP in Qt. :)

> At first we gave the internal webserver some time to host the files
> before accessing them (assuming GUPNP uses it's own webserver and does
> not access the XML-files directly from the file-system)... but this
> strategy did not solve the problem. Right now we are starting to debug
> glib because the output does not give us any hints. Up to now our
> debugging revealed that inside" gupnp_service_info_get_context()" the
> method "g_object_new()" creates somehow broken instances of
> GUPnPServiceInfo; sometimes with illegal values of GType, sometimes
> with memory allocation errors. Does anyone know how to deal with this
> problem?

Valgrind. Sounds like memory corruption. Also, which version of GSSDP do
you use with GUPnP?

> 2. Our second issue: In our application the GUPNP part needs often to
> be restarted (initialized / deinitialized). Because of this we have a
> question regarding deinitialization of GUPNP structures: The sample
> code provided on the web simply calls g_object_unref on the
> GUPnPContext; we added calls to g_signal_handler_disconnect for all
> signal-handlers we registered during the initialization phase. Is
> there anything more we should take care of?

If g_object_unref leads to destruction of the object (i.e. frees the
last reference to it), then there's no need to disconnect the signals.

Additionally a GUPnPContext can be set active/inactive. I'm not sure
what you mean by initializing/deinitializing.