GNOME Bugzilla – Bug 549401
crash when unplugging device (or unloading module)
Last modified: 2008-09-25 10:05:33 UTC
Steps to reproduce: 1. wait till supplicant has scanned 2. unplug device or remove your wifi module 3. crash This was reported as launchpad bug: 259503 in network-manager "MASTER NetworkManager 0.7 crashed with SIGSEGV in nm_device_get_act_request()" [High,Fix committed] https://launchpad.net/bugs/259503 Stack trace: gdb) bt
+ Trace 205684
341 NMActRequest * 342 nm_device_get_act_request (NMDevice *self) 343 { 344 g_return_val_if_fail (self != NULL, NULL); 345 346 return self->priv->act_request; 347 } 348 349 350 gboolean (gdb) p self $1 = (NMDevice *) 0x147a060 (gdb) p self->priv $2 = (NMDevicePrivate *) 0xaaaaaaaaaaaaaaaa Other information: Evaluation from LP bug: What appears to happen here is that NM uses a scheduled callback to perform actions on device objects. however, those device objects are neither refcounted nor are the callbacks cancelled when the device goes down and we end up accessing freed memory in the callback.
Created attachment 117384 [details] [review] 1st attempt keep an extra ref for idle callback
should really be tracking the GSource ID and removing that when the device gets unreffed. Should probably keep a GSList of active source IDs on the wifi object, add new ones to that list each call to schedule_state_handler(), and remove them from the list at the bottom of supplicant_iface_connection_state_cb_handler, supplicant_iface_state_cb_handler, and supplicant_mgr_state_cb_handler. When the wifi object is disposed, go through the list and remove all handlers from the mainloop.
Created attachment 118872 [details] [review] 2nd attempt using GSList to track pending source_ids. Further I put the source_id and the source_link (GSList *) into the state_cb_data struct to not need to run through the GSList* looking for the id to be removed. I tested it quite thoroughly for wifi. ethernet tests are still pending, but i think i got all places there.
fixed in a slightly more comprehensive manner in svn r4105, thanks! The issue was that we probably want to clean up the supplicant interface related tasks when the interface is cleaned up (but leave the supplicant manager state task running if scheduled) which required breaking up the task list into two. I also fixed the code to track and remove the supplicant interface error idle handler which it wasn't doing before.