mark at kingant.net
Mon Nov 22 05:51:20 EST 2010
On Fri, Oct 29, 2010 at 11:19 PM, Paul Aurich <paul at darkrain42.org> wrote:
> On 2010-10-07 04:18, Florian Quèze wrote:
>> 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
>> 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.
>> - the oscar plugin crashes in flap_connection_destroy_cb:
>> For more similar stacks, see
>> Some variations:
>> 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.
> That was me (both with the commit and suggestion in #pidgin). It
> definitely fixes one version of the patch, but the original ticket
> predates the addition of SSL support for OSCAR, so clearly there's
> another issue going on there. (I'm staring at the code and just not
> seeing how the crash is possible...)
> I just committed bc9c4bb89eb6d36c548b61d8b1e6b8952b9c4c0e (trivial
> printing out of pointer values), which will be helpful in correlating
> where the timeout is coming from. Logs+backtrace from this crash with
> that patch would be awesome!
I just committed 6e8da78b6e5ccdafa85c8afebff37e426d9a58d3, which I
hope will fix this.
More information about the Devel