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)
Cheers.
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/pan-users
