GNOME Bugzilla – Bug 606701
e-d-s 2.28.2 various null pointers during strtoul call
Last modified: 2010-12-09 09:39:10 UTC
Hi, don't know what caused it - perhaps some ext3 corruption that I mostly fixed. I couldn't find a "stable" version of eds to go back to so it appears not to be related to the version. I have various SEGFAULTS when receiving mail from one specific imap account. With a new user and clean login, the same account settings don't trouble it at all. Other imap accounts are ok. It's just this one account. I got a backtrace, found a NULL pointer in a call to strtoul, patched it and repeated until I had evo running again. I've attached a patch to check for NULL in the couple of macros that seemed to be causing my crash. I don't know what side-effects this patch has - it's only a hack to get me running again. The backtraces looked like this: Program received signal SIGSEGV, Segmentation fault.
+ Trace 220017
Thread 2946358128 (LWP 2211)
Thread 2963098480 (LWP 23518)
both camel/providers/imap/camel-imap-summary.c and camel/camel-folder-summary.c have the macro EXTRACT_FIRST_DIGIT which calls strtoul. It seems to me that re-coding these macros in various files using variables which aren't an arguement to the macro ("part") is slightly error prone - it might explain a few of the NEW and UNCONFIRMED segfaults I see in bugzilla about evo starting and receiving email crashes. A few if(pointer) blocks might stabilise it a bit? After getting evo running, I eventually came to a different SEGFAULT altogether. I fixed it by moving the entire ~/.evolution/mail/imap/<account>/ folder out of the way and running evo again. Not sure if this crash was related. I'll deal with that separately if it happens again. Feel free to do whatever with the patch - it might create some missing details about folders / mails, but I don't know much about the evo source code so I stopped here :) Thanks for the great mailer, regards, Iain.
Created attachment 151219 [details] [review] patch to check for NULL pointer before calling strtoul in some macros
I just realised your nifty trace detector thing has muddled up my traces slightly - look at the plain text cause I trimmed them myself. They're actually two different traces from different instances of evo.
Thanks for a bug report and a patch. I believe you've right. It would be better to have some utility functions for extracting data from bdata on one place (camel-folder-summary.h/.c) and use them all around where needed, instead of redefining them whenever possible. They can check for errors like you suggested. I'm CC'ing two other developers for their opinion on this.
I'm marking this as a duplicate of bug #573125, where is also a proposed patch. I'll merge the best from both and try to push it to sources. *** This bug has been marked as a duplicate of bug 573125 ***