GNOME Bugzilla – Bug 315987
Evolution 2.4 crashes EVERY time i sent an email
Last modified: 2013-09-10 14:03:53 UTC
Write an email, send ih, evolution crashes; I'm going to submit some back traces to make it easier for you to find out which thread the bugged one is. Number one: Backtrace was generated from '/usr/bin/evolution-2.4' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) `system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols. (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) [Thread debugging using libthread_db enabled] [New Thread -1229534304 (LWP 13101)] [New Thread -1278608464 (LWP 13141)] [New Thread -1270215760 (LWP 13140)] [New Thread -1261823056 (LWP 13122)] [New Thread -1253332048 (LWP 13120)] [New Thread -1244939344 (LWP 13118)] [New Thread -1236145232 (LWP 13116)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 62932
Thread 2 (Thread -1278608464 (LWP 13141))
crash in libgnomeui. Is there a better stack trace you can provide.
Here's another one; I don't think that it's libgnomeui; libgnomeui only creates the "evolution has crashed" dialog. The error seems to me that a g_log() message had the fatal flag set and so the application was quit (which happens e.g. in case of either a g_error() message or some statement like g_assert()). This is the information that I got on stdout (which serves as a proof for my idea): [10:13] herzi@wallace: ~ > evolution adding hook target 'source' (evolution:17956): camel-WARNING **: camel_exception_get_id called with NULL parameter. (evolution:17956): Gdk-CRITICAL **: gdk_gc_set_foreground: assertion `GDK_IS_GC (gc)' failed ** (evolution:17956): WARNING **: aspell error: No word lists can be found for the language "en_US". ** (evolution:17956): WARNING **: aspell error: No word lists can be found for the language "de_DE". (evolution:17956): camel-WARNING **: camel_exception_get_id called with NULL parameter. camel-imap-provider-ERROR **: file camel-imap-command.c: line 180 (imap_command_start): assertion failed: (store->ostream) aborting... So, If you could please turn the g_assert(store->ostream) into a g_return_if_fail(store->ostream) or a g_return_val_if_fail(store->ostream) in camel-imap-command.c at line 180, thank you.
Cool. Thanks. This is much more helpful.
Created attachment 52122 [details] [review] Quick-Fix Patch This patch (untested) should fix the current behaviour. Note that it now throws a warning, but continues to work. This way you can still track the bug (which is actually not directly located at this position) by using --g-fatal-warnings when using the debugger.
I have a rough idea why this bug happens only to me; I told evo to move the files to an imap folder, but that one doesn't exist anymore. I think that an error message (like in older versions) would be a lot better than this crash.
Thanks for the patch, an improvised one will soon get into the HEAD :)
FWIW, I'm seeing the same thing, with (as Sven guessed) an imap sent folder that no longer exists (my novell account, actually ;) So confirming and hoping this makes it into 2.12.1. :)
Agreed, should not crash if the folder selected does not exist anymore, should fall back to the default sent itsms folder instead.
Okay, i tested this thing. I selected an IMAP folder as my sent items, and i deleted it. And it surely falls back to the default Sent Items folder (local). Now am i getting the problem correct? If a folder does not exist it puts the mail in the local sent items instead. It definitely did not crash. Guess am missing something here.
*** Bug 316923 has been marked as a duplicate of this bug. ***
Yeah, i tried the same and didnt crash for me too. Probably its deleted on the server and not on the client, is that the case ? Let me try that
And when tried to append to a folder on the client and not on the server i got the following error message. Error while performing operation. Failed to append to sshreyas@wal-3.novell.com:Cabinet/OpenOffice-dev: IMAP command failed: APPEND (D107) Appending to local `Sent' folder instead. So, i guess i am missing something too
I think it's 'disable an account' and not 'delete a folder'
And it did not make it into 2.4.1... :(
re-opening based on the last comment.
Why "re-open"? It was never closed...
The bug was in NEEDINFO state, just changed in to re-opened.
Created attachment 53043 [details] [review] proposed patch This should fix the issue. Only those accounts which are enabled are shown in the From header.
Fix committed to head.
*** Bug 317345 has been marked as a duplicate of this bug. ***
Doesn't fix this situation: 1. create two accounts 2. create one sent folder on the first account 3. set the sent folder for both accounts to the sent folder from the first account 4. delete the first account 5. try to send an email from evolution => crash Reopening, sorry
Sorry. That was bad patch indeed. the reworked patch will come soon.
Created attachment 53592 [details] [review] proposed patch The attached patch fixes the issue by not loading those accounts which are not enabled in the "From" field. This fixes the issue, in the sense that there is no way for one to chose the account which is not actually enabled. I would really like some feedback on this. Thanks.
It doesn't fix the issue. Please read comment #21 again.
Ok. A few things that came up while fixing this patch. 1. Evolution should *not* be showing diabled accounts in From header of the copmoser. 2. Evolution should *not* allow the user to Send a mail if no account is enabled. (The user should be able to only save the mail). There is a patch in evolution-patches list which does the above things And since this bug is one of the consequences of the current behaviour of Evolution, i want your inputs on the above points.
Created attachment 53757 [details] [review] revised patch Ok. Since nothing ground-breaking actually came up in the discussion as to how the problem in Comment #25 be sorted out. I actually have a patch with what i feel is right. This just completes what the patch in Comment #23 tried to do.
Created attachment 53758 [details] [review] proposed patch please ignore the previous patch. It was the wrong patch. The comments in Comment #26 holds good. Thanks.
Thsi patch starts to look good for me; though I would still prefer to have a "sent always, but move to local sent folder then" behaviour. Thanks for the work on this.
But what if the account you are trying to send with is not enabled? There is no way we should be sending it. And thats what this patch does.
I had this problem. I seemed to fix it by reconfiguring the Sent Items and Drafts folders (even though the reconfiguration was to the same settings). TThe crash for me wasn't after sending the message. It was after trying to copy it back to the Sent or Drafts IMAP folder.
Created attachment 55071 [details] [review] proposed patch Ok here is final patch. Sorry for the delay
Does this fix what happens in comment #21 ?
Hey Sven, yup i have tried that case too - works fine. No problem.
i guess this is fine. We should get this in.
Patch committed to HEAD.
*** Bug 319900 has been marked as a duplicate of this bug. ***
*** Bug 323121 has been marked as a duplicate of this bug. ***
*** Bug 325805 has been marked as a duplicate of this bug. ***
*** Bug 341491 has been marked as a duplicate of this bug. ***
*** Bug 359684 has been marked as a duplicate of this bug. ***