Re: [Pan-users] use-after-free in latest pan.git [FIXED]

[walt]

On 05/11/2014 09:44 PM, Heinrich Müller wrote:
> 
> 
> Am 11.05.2014 23:52, schrieb Andrew Nile:
>> Hi Walt & Heinrich,
>>
>> I've been thinking about Walt's backtrace. I wonder if the fix is as
>> simple as moving the compression = false line up in nntp.cc. Instead
>> of
>>
>> 64:  _listener = 0;
>> 65:  l->on_nntp_done (this, health, response);
>> 66:  _compression = false;
>>
>> it becomes
>>
>> 64:  _listener = 0;
>> 65:  _compression = false;
>> 66:  l->on_nntp_done (this, health, response);
>>
>> I'm thinking this because the first line of the trace seems to nail
>> that line as the culprit. Also, on_nntp_done has the ability to delete
>> the nntp object when the connection's health is not ok
>> (nntp-pool.cc:248). The possible sequence of bogus events could be:
>>
>> - lose connection
>> - try to connect again (nntp.cc:284), enter fire_done_func
>> - turn listener off, enter on_nntp_done
>> - health is not ok, close socket & delete nntp object. return to
>> fire_done_func (nntp.cc:66)
>> - try to set compression = false on deleted nntp object. *boom*
>>
>> Having said all that, I have 0 experience with this kind of thing. I
>> also haven't tried it out yet. This could be completely wrong,
>> especially if Walt's copy is running ok now. :-)
>>
> You nailed it, I think.
> After on_nntp_done, the pool destroys the NNTP pointer and thus the object, 
> and then the assignment of _compression occurs on a heap object that's long 
> gone.
> I'll move the appropriate line. (Can't hurt anyway)

Heh.  As usual, posting the happy FIXED message guaranteed that it wasn't
fixed after all ;)

After running pan for another several hours it crashed with the same error.

What fooled me is that I forgot to compile pan with the -fsanitized flag,
which means that pan was no longer stopping several times/hour with the
use-after-free error message.

However -- more happy news.  I compiled pan with Andrew's fix *and* the
-fsanitize flag, and pan has been running happily all day and without any
of the GObject-is-null assertions that recurred briefly before pan crashed
last night.

I'm leaving the happy FIXED message as-is while I run pan overnight again
with the new fix :)  Thanks guys.