GNOME Bugzilla – Bug 579973
Evo crashes on startup
Last modified: 2009-04-24 18:28:58 UTC
Last night I updated my Fedora 10 x86_64 system from the standard repos. Now when I try to run Evo it crashes immediately. Packages are: evolution-bogofilter-2.24.5-1.fc10.x86_64 evolution-data-server-debuginfo-2.24.5-5.fc10.x86_64 evolution-data-server-doc-2.24.5-5.fc10.x86_64 evolution-webcal-2.23.91-1.fc10.x86_64 evolution-debuginfo-2.24.5-1.fc10.x86_64 evolution-spamassassin-2.24.5-1.fc10.x86_64 evolution-help-2.24.5-1.fc10.x86_64 evolution-2.24.5-1.fc10.x86_64 evolution-data-server-2.24.5-5.fc10.x86_64 evolution-conduits-2.24.5-1.fc10.x86_64 This is under KDE 4.2.2, also updated. I will post a console log and stack trace separately.
Created attachment 133184 [details] Console log of Evo crasher
Created attachment 133185 [details] Trace of Evo crasher
Looks like camel-db.c is passing a NULL string pointer to strtoul(). Changing product.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 573125 ***
Hmm, flags is NULL. It can't be NULL. Patrick is it happening always ? if so, I would like you to dump that record from folders.db. Flags is an integer, even if itz zero. cols[i] should be "0", so that we would do strtoul. Stupid that cols[0] is zero. g_ptr_array_add (data->flags, GUINT_TO_POINTER(strtoul (cols [i], NULL, 10)));
Srini, yes, it's happening always. I'm happy to dump the record if you tell me what to do. Note that I'm not even sure *which* folders.db is causing the problem but I assume it's the one associated with my Gmail account. Some background: I updated Evo last night and restarted it. It then hung "forever" trying to read a very large IMAP folder on Gmail (corresponding to the Fedora mailing list where I never delete anything). "Forever" means I left it running around midnight and at 8am it was still refreshing the folder. I killed it with --force-shutdown and restarted. That's when it crashed and keeps crashing, so I guess it could be a folders.db corruption. Will vacuuming the db fix this? poc
Not sure, if Vacuuming will fix, as that would do a different task. When the crash happens, move the gdb frame to read_uids_flags_callback Printf cols[0], cols[1] One of them would be uid and other is NULL. The folder name is fedora. sqlite3 /home/poc/.evolution/mail/imap/pocallaghan@imap.gmail.com:993/folders.db select uid,flags from fedora where uid='<replace>'; select * from fedora where uid='<replace>'; I want to see the value for it.
I'll need more hand-holding with sqlite3. Once I do the above, I'm just looking at the sqlite prompt. How do I print the value you want?
run it as a one long command line, not 4 lines as bugzilla wrapped it. Though I do not why srag didn't ask simply for SELECT * FROM fedora WHERE uid IS NULL OR flags IS NULL; instead of 2 selects.
Once you give 'sqlite3 /path/to/folders.db' you get the prompt. Give the command and it prionts on the console. Copy the console and paste me both the results.
Srini: the reason I asked is that after executing the commands I get nothing, just the prompt: $ sqlite3 /home/poc/.evolution/mail/imap/pocallaghan@imap.gmail.com:993/folders.db SQLite version 3.5.9 Enter ".help" for instructions sqlite> select uid,flags from fedora where uid='<replace>'; sqlite> select * from fedora where uid='<replace>'; sqlite> Milan: doing it your way gives this: sqlite> SELECT * FROM fedora WHERE uid IS NULL OR flags IS NULL; ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| SQL error: database disk image is malformed
SQL error: database disk image is malformed: answers. There are lot of empty records, which is the reason for crash. Did you try vaccum ?
I was waiting in case you wanted me try check something else. I'll do it now. $ for i in `find . -name folders.db` > do > echo "Rebuilding Table $i" > sqlite3 $i "vacuum;" > done Rebuilding Table ./mbox/var/spool/mail/poc/folders.db Rebuilding Table ./imap/pocallaghan@imap.gmail.com:993/folders.db SQL error: database disk image is malformed Rebuilding Table ./imap/poc@imapmail.usb.ve/folders.db Rebuilding Table ./imap/poc@imap.ldc.usb.ve/folders.db Rebuilding Table ./vfolder/folders.db Rebuilding Table ./local/folders.db Rebuilding Table ./pop/poc@pop.cantv.net/folders.db $ ... Nope, still segfaults. This is the gdb console: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffd8cc9950 (LWP 23347)] ____strtoul_l_internal (nptr=0x0, endptr=0x0, base=10, group=0, loc=0x311396c580) at ../stdlib/strtol_l.c:298 298 while (ISSPACE (*s)) I'll attach the trace separately.
Created attachment 133264 [details] Crasher trace
Patrick, seems like the folders.db is corrupted. The dupe bug is about recovering safely from this. I suggest you to back this up, for any future testing for us, as you do always. Move the folders.db and start, it should autocreate, just that it would re-download the summary again. If you have filters that cache/archive messages to local from IMAP, run evolution with FILTER_RECENT=1 environment variable, that avoids re-filtering old messages, as it is downloading old summary from server to create folders.db. Thanks.
OK, looks like that was it. It's starting up OK though it will take a while to recreate that particular folder.db as it's a very large IMAP folder. I'm going to assume the problem is fixed, but if it crashes again I'll add another comment.