GNOME Bugzilla – Bug 60785
Balsa vanishes in a puff
Last modified: 2009-08-15 18:40:50 UTC
For some time, I've had intermittent problems with Balsa quitting a fraction of a second after the main window opens (literally a fraction--about a single vertical scan). Recently, my IMAP server has been very slow, and that seems to make it more likely to happen (though still not certain!). I used to get a console message about receiving `real time signal 32', but not since some upgrade--perhaps to RH7.1, concurrent with upgrade to kernel 2.4--perhaps some other component. Gdb has always just reported a normal exit--no help whatsoever! This is pretty frustrating, especially with the afore-mentioned IMAP delays--wait a couple of minutes just to see Balsa vanish in a puff of smoke! Any ideas what's going on? Peter
I remember similar issues related to certain thread library configurations. Can you check if this problem occurs with threads disabled?
Good call! Balsa-with-threads: 0% success; Balsa-without-threads: 100% success (sample size 5 for each). The situation right now is pretty bad: 900+ ms ping times to my imap server (2 miles away, but 18 hops!). So a slow startup, at least with imap, seems to be a definite factor. I'd better get used to no threads...or fall back on the `fast imap open' patch I sent in some weeks ago.
SIG32 *is* pthread related. On a slow server balsa gets stuck on read() for much longer so i'd guess a read call is getting a SIG32 and mutt code isn't gracefull about that. I'm not sure why it would make balsa die though.
I just caught a sig32 in gdb: Program received signal SIG32, Real-time event 32. 0x4085a656 in ?? () (gdb) bt
+ Trace 12706
Lines 1723-5 are: /* initiate threads */ pthread_create(&get_mail_thread, NULL, (void *) &check_messages_thread, (void *)0); so it looks as though we were a couple of calls deep in pthread code when it happened.
I think balsa dies because the signal is not handled properly. The question is, why it is not handled. Is it legal to set own handler for this signal? What about portability? I would like to know more about pthread internals..
I have seen it once and it looks like a pthreads problem to me...
I assume this is fixed with new mailbox tree scanning code. if the problem reappears, please reopen.
You're right, I haven't seen this happen in a while--it could well have been since the new mailbox handling was installed.
BTW, balsa-1.3.7 (prerelease of 1.4.0) is available for download: http://balsa.gnome.org/