dLeyna renderer can crash if renderer dissapears (7.2.8.4,6)

[markdryan]

This crash happens if dLeyna-renderer is in the process of retrieving the introspection data for a service when the corresponding renderer disapears from the network. The problem is that we retrieve the introspection data using gupnp_service_info_get_introspection. This is a synchronous function that blocks until the introspection data has been returned or there is an error. The problem is that this function iterates the main loop. So if a renderer disappears, prv_server_unavailable_cb is called and the renderer object is deleted. When gupnp_service_info_get_introspection returns to a function such as prv_get_av_service_states_values, the proxy used to retrieve the introspection data is invalid, but prv_get_av_service_states_values has no way of knowing this.

To fix this problem properly we really need to be able to cancel gupnp_service_info_get_introspection, which means adding a new function to GUPnP.

This bug causes a failure on the DLNA test 7.2.8.4,6

[markdryan]

Here's an example stack trace of the crash:

(gdb) bt
#0  0xb7c62bf7 in gupnp_service_introspection_get_state_variable ()
   from /home/rygelplugfest/cvp2/root/lib/libgupnp-1.0.so.4
#1  0xb7fcd63e in prv_get_rc_service_states_values ()
   from /home/rygelplugfest/cvp2/root/lib/libdleyna-renderer-1.0.so.1
#2  0xb7fcdc9c in prv_props_update ()
   from /home/rygelplugfest/cvp2/root/lib/libdleyna-renderer-1.0.so.1
#3  0xb7fce71b in dlr_device_get_all_props ()
   from /home/rygelplugfest/cvp2/root/lib/libdleyna-renderer-1.0.so.1
#4  0xb7fd3308 in dlr_upnp_get_all_props ()
   from /home/rygelplugfest/cvp2/root/lib/libdleyna-renderer-1.0.so.1
#5  0xb7fd0a4c in prv_process_async_task ()
   from /home/rygelplugfest/cvp2/root/lib/libdleyna-renderer-1.0.so.1
#6  0xb7fd0c72 in prv_process_task ()
   from /home/rygelplugfest/cvp2/root/lib/libdleyna-renderer-1.0.so.1
#7  0xb7fc0e1f in prv_process_task ()
   from /home/rygelplugfest/cvp2/root/lib/libdleyna-core-1.0.so.1
#8  0xb7ec4468 in g_idle_dispatch ()
   from /home/rygelplugfest/cvp2/root/lib/libglib-2.0.so.0
#9  0xb7ec1cfb in g_main_dispatch ()
   from /home/rygelplugfest/cvp2/root/lib/libglib-2.0.so.0
#10 0xb7ec2964 in g_main_context_dispatch ()
   from /home/rygelplugfest/cvp2/root/lib/libglib-2.0.so.0
#11 0xb7ec2b4f in g_main_context_iterate ()
---Type <return> to continue, or q <return> to quit---q

[markdryan]

Also affects 7.2.3.4

[markdryan]

The more I look at this code the more broken it seems to be. Sometimes, the introspection data is retrieved synchronously inside an event callback from GUPnP. As we iterate the mainloop inside this callback, GUPnP can crash when we return control to it even if dLeyna-renderer doesn't. I'm guessing that it is also possible for us to request the introspection data twice if we receive two events in quick succession. The best way to avoid this sort of problem is to simply read the service introspection data during device construction.

So to fix properly we need to:

1. Add the gupnp_service_info_get_introspection_cancel method as described above.
2. Modify the service_task to allow us to queue calls to functions that are not gupnp actions.
3. Retrieve service introspection data during device construction.

As this proposed fix will require API changes to dLeyna-core and GUPnP, I'll try to see if I can come up with a short term work around to get rid of the crash.

[markdryan]

Fixed by PR #103. The nicer fix described above is now documented in a new issue #104.