On 02/04/15 15:15, Tomasz Bursztyka wrote: >> There are some corner cases that I have been unable to catch so far, >> which result in connman_service holding a reference to connman_network >> in connecting/associating state (albeit with driver pointer being NULL) >> but those are quite rare. That sort of things happens once in a new >> weeks of normal usage (which involves periodic switching between mobile >> data and various wifi networks) but once it does happen, connman is >> unable to recover and needs to be restarted. That's quite annoying for >> the end-users of the device. > > Yup, looks like a critical bug. If by chance you get the connman logs > of such > issue, it will be welcomed.
I think I finally caught one of the scenarios like that. The trick was to receive DISCONNECTED event from wpa_supplicant followed by ASSOCIATING while network->connecting is set to true. 1. DISCONNECTED sets device->scanning to true 2. ASSOCIATING sets device->scanning to false, which invokes remove_unavailable_network(), sets network->driver to NULL and eventually calls __connman_service_remove_from_network() for the network in question. Now the service is holding reference to the dead network, update_from_network() doesn't work because network->connecting is true, __connman_network_disconnect() doesn't work because network->driver is NULL. That's it. I just sent a patch that should prevent that from happening in two places along this course of events - by dropping reference to the dead service in __connman_service_remove_from_network() and in update_from_network(). Under this particular scenario the latter seems to be unnecessary but I'm pretty sure there are more bugs floating around so I suggest to keep both checks. -Slava _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
