GNOME Bugzilla – Bug 214092
mailer components hangs evo on startup
Last modified: 2013-09-10 14:02:36 UTC
This just started with this afternoons snapshot - Evo starts up - complains about the calendar file (see bug 214067) and hangs - won't redraw itself, nothing. I've tried running the mail component in a terminal window with CAMEL_VERBOSE_DEBUG set - no relavent messages are emitted. If I kill that process evo sometimes notices it (complains that a component has exited abnormally) and continues startup. I haven't been able to get anything useful yet (i.e. stack trace, etc.) It works on my "other" machine - also a RedHat 7.1 box running 2.4.6 - which leads me to suspect that it's related to the depth of my folder tree - but that's just a random guess at this point.
downgrading severity - I did this: % cd evolution/local % find . -name mbox.\* -exec /bin/rm {} \; (remove all the mbox.ibex and mbox.ev-summary files) Evo mail starts again - but something definitely was pissed off about one of those files. I have a backup of all of them - but there are 141 files total. If someone wants them to try and figure this one out - let me know.
ok - I'm bumping it back up - after evo sucessfully started, I exited and tried restarting - and I'm back to hanging. Once again removing mbox.* allowed it to start. I'm going to try and do a bit more diagnosis...
ok - it's something about the ev-summary files - I removed them (but left the .ibex files) and evo starts again. but once it writes out the ev-summary files, it hangs on startup. I also tried removing it just from the Inbox folder - evo still hangs. I can attach a tar file of all the .ev-summary files to this bug if you want one - but I'll hold off 'till "you" ask for it.
the problem is deeper than just a hang on startup - if I leave evo running for a few minutes it hangs - 0% CPU - just hung. The status bar reports two instances of "storing folder (0% complete)" I'm going to downgrade to the "stable" snap available under the Ximian desktop channel.
BTW: All this is occuring with evolution-0.16.99-snap.ximian.200110301608.i386.rpm
sorry to add another 1.0 at this point, guys, but this sounds ugly.
We need a stack trace for this. It definitely doesn't happen for me. Try running evolution-mail under GDB before running evolution. When the process hangs, hit C-c in GDB and do: (gdb) thread apply all bt BTW I seemed to have some ugly hangs earlier today, but they are all gone for me. I think this is what you are seeing. Can you please try updating to the latest snapshot again and tell us if this fixes it? That would be really appreciated.
Re-opening; we have at least one confirmation on the list. Please do try to get that trace, though, Dan.
I'm downloading the new snap now (at 4-5k/s - not exactly chewing up my DSL line) and will update this bug once I have it installed. I tried getting a stack trace out of the hang last night (using the procedure described above) but couldn't get gdb to interrupt the running process - kinda odd.
Ok - the new snap is still broken - here's the backtrace. Interestingly - starting evolution-mail in gdb never registered the needed IID's - so evo would start another one - I had to startup evo and attach gdb after the fact. Anyway: (gdb) thread apply all bt
+ Trace 12746
Thread 5 (Thread 3076 (LWP 6235))
Thread 4 (Thread 2051 (LWP 6232))
Thread 3 (Thread 1026 (LWP 6231))
Thread 1 (Thread 1024 (LWP 6187))
Sorry, simple deadlock introduced with a race fix in libibex. Fixed in cvs.
excellent Smithers. Any chance that fix will make the afternoon snapshot?
dan: it did not make the afternoon snap; we're trying to roll another one.
Apparently it didn't make cvs.2001.11.01.08.57 either. Running: % cd evolution/local % find . -name mbox.\* -exec /bin/rm {} \; suggested by someone else still fixes it.