Crashes in g_hash_table_iter_next call

[Sebastien Fabre]

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.fabre at sigfox.com<mailto:sebastien.fabre at 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 <aleksander at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20181128/fd6c7c1c/attachment-0001.html>