Hello,
> Have you not found the issue with MM 1.8? Or just not tried? We have not tried with MM 1.8 (we have not a method to reproduce these crashes). Do you think that "self->priv->ports" value should be checked before using it in all methods of mm-base-modem.c ? Or just destroyed and set to NULL in finalize ? Sebastien Fabre Embedded Software Engineer [http://www.sigfox.com/static/media/signature_sigfox_logo_nov16.png]<http://www.sigfox.com> Bâtiment E-volution - 425, rue Jean Rostand 31670 Labège, France sebastien.fa...@sigfox.com<mailto:sebastien.fa...@sigfox.com> sigfox.com<http://www.sigfox.com> [http://www.sigfox.com/static/media/T.png] <https://twitter.com/sigfox> [http://www.sigfox.com/static/media/F.png] <http://www.facebook.com/sigfox> [http://www.sigfox.com/static/media/L.png] <http://www.linkedin.com/company/2731408> [http://www.sigfox.com/static/media/Y.png] <https://www.youtube.com/sigfox> ________________________________ De : Aleksander Morgado <aleksan...@aleksander.es> Envoyé : mardi 27 novembre 2018 17:43:59 À : Sebastien Fabre Cc : ModemManager (development) Objet : Re: Crashes in g_hash_table_iter_next call Hey > With different versions of ModemManager (1.6.12, 1.6.4, 1.4.2), we have seen > (rarely) segfault crashes in g_hash_table_iter_next called by > mm_base_modem_find_ports because the hash table corresponding to ports is > NULL. > When the crash occurs, in mm_base_modem_find_ports (mm-base-modem.c), > "self->priv->ports" and "self->priv->authp" are NULL. It seems that they can > be NULL only if dispose was called before but the reference count of the > object is not equal to 0 (7 for example). Maybe because g_object_run_dispose > was called. > Unfortunately, we do not have a method to reproduce these crashes even if it > seems to occur at modem unplug (huawei models - broadband). > Is it a known problem? > I believe we should be checking for self->priv->ports being not NULL in that method, that should solve this problem. This looks like a race when the modem gets unplugged indeed, but my impression is that a dangling modem reference left unref-ed could also increase the chances of this occurring. Have you not found the issue with MM 1.8? Or just not tried? -- Aleksander https://aleksander.es
_______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
