GNOME Bugzilla – Bug 561332
Evolution crash while loading folders due to removed message
Last modified: 2013-07-23 14:27:32 UTC
Steps to reproduce: 1. 100% of time crash while loading folders and mails from exchange Stack trace: Program received signal SIGSEGV, Segmentation fault.
+ Trace 209956
Thread 3056183072 (LWP 15083)
Other information: Cannot see any e-mail...
Created attachment 122931 [details] [review] This patch fix the problem with the exception caused by removed mails. When it reach to the line 1217. while (highest_unverified_index > -1) { It tries to delete remaining unverified mails some of them are already deleted by previous while (line 1166). So it's best to get again this index. This is what this patch does
Similar to http://bugzilla.gnome.org/show_bug.cgi?id=501132#c5 and bug 554880
bug 522277 also looks on same lines
The second one does not look the same (bug 522277)
I had similar problem, but my fix looks this: --- mail-stub-exchange-old.c 2008-12-04 12:43:18.000000000 +0100 +++ mail-stub-exchange.c 2008-12-04 12:43:45.000000000 +0100 @@ -1190,7 +1190,8 @@ */ while (my_mmsg->seq != mmsg->seq) { mfld->deleted_count++; - message_removed (stub, mfld, my_mmsg->href); + if (my_mmsg->href != 0x0 ) + message_removed (stub, mfld, my_mmsg->href); changes = TRUE; my_i--; my_mmsg = mfld->messages->pdata[my_i];
Looks good also. I will use NULL instead 0x0. Just to be a little picky.
Similar bug appears also in version 2.24.3 in Ubuntu. But the program hang on another line #1223, at message_removed() g_hash_table_lookup(), g_str_hash() (dumps from gdb are similar with previous ones) /* Clear out the remaining messages in mfld */ while (highest_unverified_index > -1) { mmsg = mfld->messages->pdata[highest_unverified_index--]; message_removed (stub, mfld, mmsg->href); changes = TRUE; } A checking NULL value in mmsg-href doesn't work any more. Any hints to check ?
Hi, I think they are doing a architecture redesign on this. Have you tried to put the 0x0 check before the message_removed?
I've tested it, but unfortunately it doesn't work. After this workaround I wasn't able to move messages between folders. Maybe there would be better to place g_hash_lookup_extended(...) function, which better handles hash keys even with null values.
Yep, for sure. I'm sorry but not really a evolution developer. Just did the patch because was easy to fix. I even don't know the architecture. Maybe someone else can help?
*** Bug 572485 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > It tries to delete remaining unverified mails some of them are already deleted > by previous while (line 1166). So it's best to get again this index. Your reason makes sense, though the highest_unverified_index can be set to -1 already, at line 1204, thus there should be rather some min of those. I tried to simulate this, (with copying some message to Inbox, closing evo, and deleting some of them in an OWA interface, but no luck, it doesn't want to crash to me. Just by a chance, do you have some steps how to re-trigger this?
Hi Milan Crha, For me it was triggered because it existed one folder in EVO called "Norton Antispam folder" that seemed not to exist anymore in exchange or was hidden/deleted. Maybe you can try to create a folder. Fetch it with evo. And delete it without evo. Just with a webmail access or something of the like. This should trigger the bug.
Yup, this crashes eex for me too, though in a different place:
+ Trace 213107
I can also reproduce the same when renaming folder within evolution, but not always. My source lines are:
+ Trace 213109
1221 1222 /* Clear out the remaining messages in mfld */ 1223 while (highest_unverified_index > -1) { 1224 mfld->deleted_count++; 1225 mmsg = mfld->messages->pdata[highest_unverified_index--]; 1226 message_removed (stub, mfld, mmsg->href); 1227 changes = TRUE; 1228 } 1229 1230 if (changes) (gdb) p highest_unverified_index $1 = 19 (gdb) p mfld->messages->len $2 = 21 (gdb) p *mmsg $3 = {uid = 0x8d9f7b0 "0000001797c2", href = 0x0, seq = 20, flags = 16, change_flags = 0, change_mask = 0, tag_updates = 0x0} thus I believe checking for NULL href in message_removed, as suggested by mizu, would help here too. Other thing I found here is incomplete memory free on error, which can be triggered by an error on a folder, where is called got_folder_error, which frees only mfld structure but doesn't remove it from the folders_by_name. Unfortunately, the structure can be holded by other function already, thus it isn't enough to remove it from folders_by_name. I wonder whether removing it is necessary at all, at least for error cases. Is anybody of you able to make some tests when I upload here a test patch, please?
Created attachment 129946 [details] test patch for evolution-exchange; this is a test patch. it writes on evolution-exchange-storage console messages when something goes wrong, but it shouldn't crash. If you can, please try that out and let me know. It includes all the things you both mentioned. Thanks in advance.
see bug 567042 also
*** Bug 590743 has been marked as a duplicate of this bug. ***
*** Bug 594804 has been marked as a duplicate of this bug. ***
*** Bug 594806 has been marked as a duplicate of this bug. ***
*** Bug 598591 has been marked as a duplicate of this bug. ***
The "evolution-exchange" package only supports Exchange 2000 and 2003 servers. Newer versions such as Exchange 2007 and 2010 are not supported by "evolution-exchange". It is required to use the package "evolution-ews" (or to some extend "evolution-mapi") for newer version fo Exchange servers. If the problem/request described in this report still happens with a recent version of "evolution-ews" or "evolution-mapi", please add a comment to this report (and update the "product" setting accordingly if possible). There are currently no plans to continue the development of the package "evolution-exchange", so this report will soon be closed as WONTFIX. Thanks for your understanding and sorry that the reported problem was not solved in time in the package "evolution-exchange".
evolution-exchange only supports the older Microsoft Exchange server versions 2000 and 2003. The last stable release of evolution-exchange was 3.4.4 which took place a year ago. evolution-exchange is now deprecated and not under active development anymore. It is unlikely that there will be any further active development. Closing this report as WONTFIX as part of Bugzilla Housekeeping. Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again. Also feel free to reopen this ticket and change the "Product" field accordingly if the reported issue still happens with a recent version (newer than version 3.6) of one of those Exchange backends that are still supported. Please see https://help.gnome.org/users/evolution/3.8/exchange-connectors-overview.html for more information on available backends.