GNOME Bugzilla – Bug 694454
make check fails with segfault
Last modified: 2014-12-08 16:27:10 UTC
gupnp-igd consistently fails its checks in jhbuild: make[3]: Entering directory `/home/ubuntu/gnome/checkout/gupnp-igd/tests/gtest' /simpleigd/new: OK /simpleigd/default_ctx: OK /simpleigd/custom_ctx: OK /simpleigd/thread: OK /simpleigd/invalid_ip: /bin/bash: line 5: 31218 Segmentation fault (core dumped) XML_PATH=. G_SLICE=debug-blocks LD_LIBRARY_PATH=../../libgupnp-igd/.libs:/home/ubuntu/gnome/packages/lib64 ${dir}$tst FAIL: gupnp-simple-igd ====================================== 1 of 1 test failed Please report to http://www.gupnp.org/ ====================================== See the full log on https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-gupnp-igd/84/artifact/gupnp-igd.log, and thie previous history on https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-gupnp-igd/ I can reproduce a segfault on my workstation (with full X.org, network, D-BUS etc.) as well, but it looks slightly different: make[3]: Entering directory `/home/martin/upstream/gupnp-igd/tests/gtest' /simpleigd/new: OK /simpleigd/default_ctx: (/home/martin/upstream/gupnp-igd/tests/gtest/.libs/lt-gupnp-simple-igd:10907): GLib-GObject-WARNING **: invalid unclassed pointer in cast to `GUPnPNetworkManager' /bin/bash: line 5: 10907 Trace/breakpoint trap (core dumped) XML_PATH=. G_SLICE=debug-blocks LD_LIBRARY_PATH=../../libgupnp-igd/.libs:/home/martin-scratch/gnome/lib64 ${dir}$tst FAIL: gupnp-simple-igd ====================================== 1 of 1 test failed
The stack trace on my local jhbuild:
+ Trace 231548
This is actually a bug in GUPnP itself, the NetworkManager context manager does not hold a ref to itself while doing async calls and can get disposed of before they return. Patches for that are attached. Then we get to another problem, the signals are emitted after the application has released all references to the ContextManager, which is kind of annoying. Probably the GUPnPContextManager should be an object that hides that fact (otherwise, we need a gupnp_context_manager_destroy() method). Also, there is a GCancellable inside GUPnPNetworkManager, but it is never used to cancel anything. That may be a good start. @Martin: You may want to switch to the Linux ContextManager, as it doesn't seem to exhibit these issues.
Created attachment 247686 [details] [review] Indentation fix
Created attachment 247687 [details] [review] Make NMDevice into a refcounted structure
Created attachment 247688 [details] [review] Hold references while doing async calls
Comment on attachment 247686 [details] [review] Indentation fix Attachment 247686 [details] pushed as 78109f1 - Indentation fix
Attachment 247687 [details] pushed as c0fca00 - Make NMDevice into a refcounted structure Attachment 247688 [details] pushed as a9e09f0 - Hold references while doing async calls
The commit "Hold references while doing async calls" introduces a circular reference bug. You can't make one thing reference another, and have that other thing reference the original thing. As it stands now, creating a context manager object and then unref-ing it does not actually destroy the object. See https://github.com/01org/dleyna-renderer/issues/149 for how this was discovered. You should test your code with valgrind for leaks like this one, by the way.
I filed a separate bug for this: https://bugzilla.gnome.org/show_bug.cgi?id=741257