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