GNOME Bugzilla – Bug 729546
[IMAPx] Crash after large message download cancel
Last modified: 2014-07-01 09:37:01 UTC
[asinha@ankur-laptop ~]$ rpm -qa \*evolution\* evolution-debuginfo-3.12.1-1.fc20.x86_64 evolution-ews-3.12.1-1.fc20.x86_64 evolution-data-server-3.12.1-1.fc20.x86_64 evolution-help-3.12.1-1.fc20.noarch evolution-3.12.1-1.fc20.x86_64
+ Trace 233559
I've been running evolution in gdb to catch this crash, since abrt doesnt work with COPR stuff. I hope this stack trace is useful. The crash happens quite often, but quite randomly.
Another crash:
+ Trace 233560
And another:
+ Trace 233561
Please install the debug package for evolution-data-server so the traces have filename, functionname and linenumber information.
(In reply to comment #3) > Please install the debug package for evolution-data-server so the traces have > filename, functionname and linenumber information. Apologies. I've installed the debuginfo package. I'll update the bug with fresh stack traces when evolution crashes next time. Thanks, Warm regards, Ankur
I think this should be a proper back trace:
+ Trace 233572
Just had another crash:
+ Trace 233573
Full traces welcome with all threads.
(In reply to comment #7) > Full traces welcome with all threads. Ran into a dnf debuginfo bug. Will get this done ASAP https://bugzilla.redhat.com/show_bug.cgi?id=1096507
*** Bug 729997 has been marked as a duplicate of this bug. ***
Thanks for a bug report. The backtraces are fine. I didn't get any of it myself yet, unfortunately.
Created attachment 276509 [details] Complete multi thread backtrace Hi, Please find the complete backtrace attached. It's quite large. It was another random crash. I hope they're all related. Thanks, Warm regards, Ankur
(In reply to comment #11) > Please find the complete backtrace attached. It's quite large. It was another > random crash. I hope they're all related. It's the same as comment #5. I think you can stop adding more backtraces here, they are repeating. More interesting would be to know your IMAP settings and the reason why this happened, but the later is hard to guess. I know the rough circumstances, it's when a certain folder is updating, but I do not see a reason why it does what it does (yet).
I just noticed that you are running Fedora with 3.12.1 of evolution-data-server. Could you update it to 3.12.2, once it'll be available, please? Just in case, because there had been done many changes between 3.12.1 and 3.12.2 in the IMAPx code, maybe some of them fixed this as a side effect.
(In reply to comment #13) > I just noticed that you are running Fedora with 3.12.1 of > evolution-data-server. Could you update it to 3.12.2, once it'll be available, > please? Just in case, because there had been done many changes between 3.12.1 > and 3.12.2 in the IMAPx code, maybe some of them fixed this as a side effect. Oops, no, I take this bag, the current git master version suffers of the same issue, I just managed to reproduce this locally.
The main issue with the GET_MESSAGE job was that it could be done in chunks, if the message was large enough. These chunks meant multiple commands of the job. Once the command ends there was scheduled another command, in a way of remembering GList link to it, but the the call of imapx_command_start_next() could be called recursively, as is shown in comment #1, thus reusing the same GList link, which could be freed in the upper call, which means a bang. Another issue was with "tmp" files, when downloading messages. Cancelled jobs were "finished" immediately, which means that if there was waiting any other message download for this result, then it was released before the previous command completely finished, and reused the "tmp" file. The initial command them deleted the "tmp" file and the next command, now running, reported various errors, usually something like "Failed to copy the tmp file: No such file or directory". Yet another issue could be (I guess this one, but the others are verified) with error "Empty cache file". That could happen when the "tmp" contained a 0-sized file. These can be there after above issue, I guess. Yet another issue could be that some commands/jobs were starving in a queue, thus the UI could show something like "Retrieving message '3'...", but the imapx_parser_thread() was effectively idle and waiting for jobs. There was also mentioned that job->commands property could be modified from multiple thread, to which I agree, thus I made it use memory barriers (by g_atomic_int_... functions). I also added a nice debugging function "camel_imapx_store_dump_queue_status()", which shows what the store thinks is pending. All this is committed in sources: Created commit 2d4f35c in eds master (3.13.2+) [1] Created commit 1479f26 in eds evolution-data-server-3-12 (3.12.3+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=2d4f35c
*** Bug 730061 has been marked as a duplicate of this bug. ***
Hi Milan, Any chance these fixes could be pushed to the 3.12 COPR repository please? Evo is still crashing for me here since the repo is still at 3.12.2, and I can't find any information on when the repo will be updated to 3.12.3 - I can't test it out yet :/ Thanks, Warm regards, Ankur
The Fedora COPR should be updated by the end of this week, I guess, there were done changes on Monday, but the build may take some time, together with the change propagation and so on.
(In reply to comment #18) > The Fedora COPR should be updated by the end of this week, I guess, there were > done changes on Monday, but the build may take some time, together with the > change propagation and so on. Just received the update. No crashes yet. Thanks Milan! :)
*** Bug 732173 has been marked as a duplicate of this bug. ***
*** Bug 732455 has been marked as a duplicate of this bug. ***