Outstanding crashes

[Florian Quèze]

Hello,

Libpurple has been upgraded from 2.6.6 (which was used for Instantbird
0.2) to 2.7.3 in nightly builds of Instantbird about two weeks ago, so
the crash data that we collect may be relevant again to you.
Our crash reports database can be queried at
http://crash-stats.instantbird.com/query

I've checked the data this morning and if we except the uninteresting
reports (very old versions, crashes in plugins that we know nothing
about, ...) and the netsoul plugin crashes (already fixed, the bug was
trivial), we are currently seeing at least 2 (or 3) crashes in
libpurple that probably deserve some attention: 1 (or 2) new crashes
in MSN (may be somewhat related to upnp) and one in oscar, that was
already in libpurple 2.6.6.

- We have a null-printf crash in msn_slpmsg_sip_new. From what I've
been told it usually happens within 2 minutes of the connection of an
MSN account.
We also have crash reports where it happened with a much longer
uptime, but the delay may be because the user has manually connected
the MSN account.
The stack is http://crash-stats.instantbird.com/report/index/5724c46e-466c-4011-b576-813ba2101005
More reports of the same issue (the stacks are very similar, if not
completely identical):
http://crash-stats.instantbird.com/report/list?product=Instantbird&query_search=signature&query_type=exact&query=&date=&range_value=2&range_unit=weeks&process_type=all&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=strlen%20|%20_g_gnulib_vasnprintf

- We have a significant number of crashes in
msn_slp_sip_recv/msn_dc_destroy/purple_network_listen_cancel, with
variations in the stacks. I suspect the variations may be randomly
caused by using already free'd memory.
Some stacks for this problem:
http://crash-stats.instantbird.com/report/index/04db0e2f-7960-4d1a-99c1-7b2852100924
http://crash-stats.instantbird.com/report/index/5f6f9cde-c75f-4617-892a-59ae32100924
http://crash-stats.instantbird.com/report/index/55570e5d-b219-42b2-8302-9a3052101003
http://crash-stats.instantbird.com/report/index/b8c75404-aafc-48e6-8620-01ef52100924
http://crash-stats.instantbird.com/report/index/f092d332-97c8-40e8-9701-bb14e2101003
http://crash-stats.instantbird.com/report/index/cbd67728-06ef-4262-a63f-ab8a12100924
http://crash-stats.instantbird.com/report/index/2974f554-95f7-4804-8488-202022100929
http://crash-stats.instantbird.com/report/index/2f2881da-6cad-495a-896e-ca7392100924
This seems similar to http://developer.pidgin.im/ticket/12387 I'll try
to apply the patch available there, and we will see if it disappears
in the next nightlies.


- the oscar plugin crashes in flap_connection_destroy_cb:
http://crash-stats.instantbird.com/report/index/40bbf7ab-0ea3-4e96-9dc0-6dbf62101001
For more similar stacks, see
http://crash-stats.instantbird.com/report/list?product=Instantbird&query_search=signature&query_type=exact&query=&date=&range_value=2&range_unit=weeks&process_type=all&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=g_slist_remove
Some variations:
http://crash-stats.instantbird.com/report/index/d447ebe8-d025-4b3b-8b9a-964a32100924
http://crash-stats.instantbird.com/report/index/5c95337a-21e3-4f75-938a-b25222100929
The crashes that are in version 0.2 of Instantbird are with libpurple
2.6.6, the less-than-two-weeks-old crashes of version 0.3a1pre are
with libpurple 2.7.3.
>From what I've been told by users, this crash happens mostly when a
laptop wakes up from sleep and is connected to a different network.
It seems flap_connection_destroy_cb is called from a timeout after the
connection has already been destroyed.
I've already shown this crash in #pidgin a few months ago and it was
suggested that https://hg.instantbird.org/instantbird/rev/f2d45147098b
may fix it, but the crash reports we are still getting show it still
isn't fixed.
This looks like what is described in
http://developer.pidgin.im/ticket/5927 I left a comment there. I'm
surprised it's still not fixed after 2 years given how common it seems
to be (it was the most common libpurple crash in Instantbird 0.2), but
maybe the frequency of the crash wasn't known, or has increased
recently.

I hope this data will be useful to you.
If these crashes are already known, please let me know if there's some
info I've missed about them or potential fixes in Trac that I should
try.

Cheers,

-- 
Florian Quèze