GNOME Bugzilla – Bug 316071
evolution crashes on quit
Last modified: 2013-09-13 00:48:06 UTC
This bug has been opened here: http://bugzilla.ubuntu.com/show_bug.cgi?id=15175 "Evolution crashes when I quit. This only happens when I used the mail view. I have two imap servers added. Just before the crash dialog opens i can see the number of messages in the "Unmatched" vfolder go up, the number is back to normal on the next run. This is the last message on the command line: camel-ERROR **: file camel-object.c: line 242 (cobject_finalise): assertion failed: (o->ref_count == 0) aborting... ... > Thanks for your bug. What version of evolution/ubuntu do you use? Seems to be the same issue as http://bugzilla.gnome.org/show_bug.cgi?id=269903. ... I'm running breezy, evolution version 2.4.0-0ubuntu2. The crash happens every time, no matter if i use 'quit' or 'close'. I think it is related to my profile, I removed one of my imap servers yesterday, added it again and everything worked fine, but today I'm back to 'crash every time on quit'. Maybe I should delete the whole profile and re-setup evolution, copying my tasks, contacts and calenders to the new profile ? ... > Could you get a backtrace with debug packages installed (https://wiki.ubuntu.com/DebuggingProgramCrash) before moving the files? ... > Thanks for the backtrace, it's still not a debug one though. Do you use some vFolder as decribed by http://bugzilla.gnome.org/show_bug.cgi?id=306345 comments? ... Hi, yes it is definitly vfolder related, deleting all vfolders and creating new ones fixes the problem. Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run --sync Starting program: /usr/bin/evolution --sync [Thread debugging using libthread_db enabled] [New Thread -1230809408 (LWP 6326)] adding hook target 'source' [New Thread -1239077968 (LWP 6333)] [New Thread -1247466576 (LWP 6334)] [New Thread -1255855184 (LWP 6335)] [New Thread -1264243792 (LWP 6336)] [New Thread -1273631824 (LWP 6337)] [New Thread -1284080720 (LWP 6338)] Program received signal SIGABRT, Aborted. [Switching to Thread -1284080720 (LWP 6338)] 0xb78b4ab7 in raise () from /lib/tls/libc.so.6 (gdb) thread apply all bt full
+ Trace 62952
Thread 1 (Thread -1230809408 (LWP 6326))
Continuing. Program exited with code 01. (gdb) debug backtrace from gdb"
I presume, this happened after an upgrade. please recreate your vfolder rules (deleting the current ones). This should get it working. This is just a work-around though. :)
sebastian, are you still seeing this problem happen??
Created attachment 55812 [details] backtrace from crash on quit by broken vfolders Hi, I originally reported this bug at http://bugzilla.ubuntu.com/show_bug.cgi?id=15175 . I recompiled evolution with nostrip and noopt today, because of #314576. So i tried my old vfolder settings and they crash dapper drakes evolution 2.5.2. I attach a new backtrace and i can email a tarball with the broken vfolder settings if you want to close this bug.
Reopening according to the previous comment, thanks for the backtrace!
Pasting contents of the previous attachment
+ Trace 65843
Thread 3 (Thread -1246205008 (LWP 15550))
Hey seb, am sure i had fixed this issue as a part of some other patch for a crasher. Could you just check with the latest sources on HEAD and make a closure on this issue?? Thanks.
I've put a comment on the Ubuntu bug about that
Distribution bug comment: "http://librarian.launchpad.net/1546912/evolution2.5.90.txt Hi, Evolution still crashes. If I follow the instructions from https://wiki.ubuntu.com/DebuggingProgramCrash i don't get a stack trace. Shall I try to build from cvs?"
Is evolution or evolution-data-server supposed to contain the fix for that? Does .90 has it?
Partha: ^^^^^ ???
I get that too... camel-ERROR **: file camel-object.c: line 242 (cobject_finalise): assertion failed: (o->ref_count == 0) aborting... jason@tabby:~$ I too have two pop accounts. it only seems to happen if I check the mail... if I don't check and exit, I don't get the crash. Ideas?
I've managed to consistently reproduce/remove/reproduce what I think is this same bug in evolution 2.4.2.1 :) I have a hunch the issue is vfolders which are based on other vfolders. ie: 1. Create a vfolder based on all local/external folders - let's call it "Last Week" 2. Create a new vfolder based on Last Week - let's call it "Unread Last week" Every time these vfolders are updated (ie new mail, deleted mail, changed mail), Exit -> Crash.
Heikki, good catch. This may very well be. There are a bunch of "crash on close" bugs, that are suspected to be related to vFolders. However, you are not entirely clear about your observations. Can you reproduce this with any vFolders and fetching mail, or with cascaded vFolders only? Can you reliably fetch mail and exit without a crash, after some modifications? If so, did you remove all vFolders or just don't use cascaded ones? Hope, I'm not confusing... ;)
Karsten: I can reproduce the crash on exit with any cascaded vfolders. When I remove the cascading, I also remove the crash :)
Confirming this bug, I dont remember any fix has gone in recently with respect to this bug.
Anything I can do to help solve this bug... I use vfolders, but no imap. Sometimes it doesn't crash with an error... If I don't get email it ussually doesn't crash... and sometimes when I check for email when leaving the program it doesn't give an error.
related to bug 330157 ??
Trying to reproduce the bug - following Heikki's steps.
With edgy it is doing it again. Grrr....
I have recently upgraded to feisty and haven't seen evo 2.9.6 exhibit this behavior.
Does anybody else still see the problem in 2.9.x?
From https://launchpad.net/ubuntu/+source/evolution/+bug/21399 Hi, I just copied my one year old vfolders.xml onto .evolution/mail/vfolders.xml. This file was known to trigger the bug, but does not anymore. I think the 'UNMATCHED' folder in vfolders.xml was the problem last year: <sources with="specific"> <folder uri="email://vfolder@local/UNMATCHED"/> <folder uri="email://111111111.11111.0@hostname/INBOX/Groups/All"/> </sources> Currently i can't reproduce the bug on edgy. I think it's safe to close the bug.
The ubuntu bug has been marked fixed, doing the same for the upstream one. Feel free to reopen if you think that's wrong