GNOME Bugzilla – Bug 112839
crash on deleting mail
Last modified: 2009-08-15 18:40:50 UTC
Package: balsa Severity: normal Version: 2.0.10 Synopsis: crash on deleting mail Bugzilla-Product: balsa Bugzilla-Component: general BugBuddy-GnomeVersion: 2.0 (2.2.0.1) Description: Description of Problem: crash on deleting mail Steps to reproduce the problem: 1. 2. 3. Actual Results: Expected Results: How often does this happen? random Additional Information: Sorry, I know that the description is not of much use. Balsa tends to crash randomly. In this case I was punching Delete with a dozen or so items (everything in the folder) highlighted. Debugging Information: Backtrace was generated from '/usr/bin/balsa' (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...[New Thread 16384 (LWP 640)] [New Thread 32769 (LWP 716)] (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...0x40d91844 in waitpid () from /lib/libpthread.so.0
+ Trace 36803
Thread 1 (Thread 16384 (LWP 640))
------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-05-12 10:41 ------- Reassigning to the default owner of the component, pawsa@theochem.kth.se.
I could have sworn I've seen similar stack traces, but according to the simple-dup-finder, this appears to be a unique stack trace. Setting version->2.0.x, marking priority->high & severity->critical (it's a crasher), adding bugsquad keyword, and marking as new.
Does upgrade to 2.0.11 fix that problem?
Regretably, upgrading to 2.0.11 does not fix the problem. Stack trace is pretty much the same. The crashing appears to to be related to deleting; I've seen it happen (2.0.10) when there was no activity at all. I'll be glad to assist in diagnosing the problem. Just let me know what needs to be done.
Thanks for the reply. What OS is this? Linux?
OS is Linux -- RH 9
*** Bug 112408 has been marked as a duplicate of this bug. ***
Some additional observations. These relate to 2.0.11, but I suspect are also relevant to 2.0.10. I notice that Balsa does its segv thing more often in the early morning. That's relevant because when I go on-line there are several dozen emails waiting. The sequence of events for a new mail is fetchmail->sendmail->MailSorter->balsa MailSorter is a locally-written Perl daemon that looks at the .forward file being filled by sendmail (not the same as balsa's inbox) and distributes mail (using Email::Filter) to balsa's inbox or to one of balsa's maildir-style folders. My guess is that balsa is not expecting things to be added by outside actors. The delivery mechanism (Email::LocalDelivery) uses a maildir mechanism of write to maildir/tmp followed by linking the file to maildir/new. For the mbox inbox, it uses flock LOCK_EX | LOCK_NB, followed by append to the file and unlock.
Miquel van Smoorenburg filed a similar bug report on the Debian BTS at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=191851 with instructions as to how to fully reproduce it. The only thing different here is that this is with Debian GNU/Linux (unstable). I can't produce it on my POP3 setup, so it might be a remote IMAP bug as Miquel suggests.
Interesting. I commited a fix on December (it's on 2.0.4) for a problem with maildir being changed externaly and balsa not dealing correctly with it. I wonder if this is still related. However, you say that it happens with mbox too right ?
With both mbox and maildir, as far as I can tell. Here's a recent stack 2.0.11 unmodified, locally compiled. at balsa-message.c:617 part_count = 1096009912 has_focus = 0
+ Trace 38071
*** Bug 117323 has been marked as a duplicate of this bug. ***
*** Bug 124536 has been marked as a duplicate of this bug. ***
*** Bug 126094 has been marked as a duplicate of this bug. ***
Is this bug still relevant ? can it still be duplicated with recent versions ?
It does not occur with 2.0.16. However, FWIW, I've changed the environment from a Pentium Pro with 256KB memory to a dual Opteron with 4G. I think that the increased available resources may have something to do with the improved results. :-)
Seems like it's fixed
*** Bug 171816 has been marked as a duplicate of this bug. ***