GNOME Bugzilla – Bug 757789
[IMAPx] Incorrect unref of a message info on message copy
Last modified: 2016-02-17 16:44:19 UTC
Hello, I just selected an IMAP folder and deleted it. Evolution warned me about all included messages that would be deleted, and I accepted it. Then evolution crashed as shown in the following backtrace. I then restarted evolution and found the folder was really deleted and all messages were in the Trash. So, it might be crashed after the folder was successfully deleted. This is Debian testing with evolution 3.18.1. Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt full
+ Trace 235697
A second try, on a different folder, produced a different backtrace: Program received signal SIGSEGV, Segmentation fault.
+ Trace 235698
Thread 140734736889600 (LWP 11881)
(gdb)
I did some more testing and found that the same problem happens even when not deleting folders. This is a backtrace of a crash after moving a message from inbox to a different folder: Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt full
+ Trace 235702
Thanks for a bug report. I tried to reproduce this, but no luck. It seems you are able to reproduce this consistently, thus I'd like to ask you for any details you can share to reproduce the crash. You are right that this happened only after the message/folder had been deleted, as this crashed after the message list had been rebuilt and the previously selected message was about to be selected. It can be anything from the used view (threaded/not threaded, wide/classic view, show/hidden deleted messages, certain sort ordering, and so on) and the selected message you tried to move (to/bottom of the message list, leaf/middle/root node of some thread, ...) and how you moved it (drag&drop, through context menu, keyboard shortcut,...). Any detail matters. Thanks in advance.
I use threaded view, hiding deleted messages, sorted by date (top older, bottom newer). I moved a message (a thread composed by only that message, so it was root and leaf of the thread) dragging it with mouse over the destination folder name. I don't know what the wide/classic view are. Could you explain that? Is there anything mode I can do? Do you have special arguments I should use when running evolution? Or, do I need to install any package? Thanks, Giuseppe
(In reply to Giuseppe Sacco from comment #4) > I use threaded view, hiding deleted messages, sorted by date (top older, > bottom newer). I moved a message (a thread composed by only that message, so > it was root and leaf of the thread) dragging it with mouse over the > destination folder name. Hmm, I tried the same here. > I don't know what the wide/classic view are. Could you explain that? You can change it in View->Preview menu. I see I used wrong terms, they are called Classic and Vertical view. > Is there anything mode I can do? Do you have special arguments I should use > when running evolution? Or, do I need to install any package? I do not have anything for these. You already seem to have installed debuginfo package for the evolution (your backtrace gives exact line numbers). Maybe if you try to reproduce it under valgrind, but that is quite slow. Considering that we do exactly the same steps and I'm not able to reproduce this, I'm wondering how much this is related to "proper timing", which the run under valgrind can "break", due to its slowness. If you want to give it a try, the command would look like: $ G_SLICE=always-malloc valgrind evolution &>log.txt
Hello, I just got a new SISEGV. This time I selected a few threads and applied all rules for moving them in specific folders. Evolution got the signal and I still see all these messages selected in my INBOX. This stack trace is longer than the previous one, so I don't know if it can be helpful. Could you check if the stack trace is the same? Tomorrow I'll give it a try at valgrind. Program received signal SIGSEGV, Segmentation fault.
+ Trace 235713
Thread 140734736889600 (LWP 6473)
Created attachment 315214 [details] valgrind log Valgrind log of Evolution crashed after deleting an imap folder. Bye, Giuseppe
(In reply to Giuseppe Sacco from comment #6) > This stack trace is longer than the previous one, so I don't know if it can > be helpful. Could you check if the stack trace is the same? It's a different place. Looks like a memory corruption, some code probably wrote somewhere where it should not or some structure was freed before it should be freed. The valgrind caught both issues, and looking into it it seems to me that they are related. Would you mind to install debuginfo packages for the evolution-data-server and evolution, please? I do not need debuginfo for their dependencies, the debuginfo only for them two would be great. That will show also line numbers, eventually will make the backtrace more detailed. I can see some things even without that, based on the shown function numbers, thus it's not a problem if you'll not have a time or resources to do it. What I understand from the valgrind log is that the add_present_rec() in camel-folder-thread.c freed the CamelMessageInfo structure by unreferencing its last reference. It looks like the dereference is correct, at least after a brief code reading, thus it can be that some calls related to the message move and/or the folder deletion did the message info unref incorrectly and it caused the crash. I'll investigate further and will let you know as soon as I'll have something. Thanks for your help with this.
I cannot really understand what you mean: the packages you request are already installed. What am I missing? giuseppe@uefi:~$ LC_ALL=C dpkg -l \*evolution\*| grep -v ^un Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============================-==================-============-========================================================== ii evolution 3.18.1-1 amd64 groupware suite with mail client and organizer ii evolution-common 3.18.1-1 all architecture independent files for Evolution ii evolution-data-server 3.18.1-1 amd64 evolution database backend server ii evolution-data-server-common 3.18.1-1 all architecture independent files for Evolution Data Server ii evolution-data-server-dbg 3.18.1-1 amd64 evolution database backend server with debugging symbols ii evolution-dbg 3.18.1-1 amd64 debugging symbols for Evolution ii evolution-plugins 3.18.1-1 amd64 standard plugins for Evolution ii libevolution 3.18.1-1 amd64 evolution libraries ii libreoffice-evolution 1:5.0.3~rc2-1+b1 amd64 office productivity suite -- Evolution addressbook support ii openoffice.org-evolution 1:3.4.0~ooo340m1-7 all office productivity suite -- Evolution addressbook support
Weird, neither gdb nor valgrind is using those -dbg packages, while you have both of them of the right version, thus it should just work. The backtrace should show also source files and line numbers in the backtraces, if everything works fine. Never mind then, the info in them is also useful, only not that detailed.
I've got it. The problem is that the routine which copies (moves) messages within the server unreferenced the message info twice, which caused a use-after-free in later calls, like the one in comment #0. I wasn't able to reproduce this, then I realized that the COPYUID status is not passed back properly, thus I fixed that, but even that wasn't enough. Finally, I figured from the valgrind log that you've setup a real Trash folder for your IMAP account. That made the difference and I also got a crash on folder deletion. The thing is that with the real Trash folder the routine to copy messages into that Trash folder is called, thus it garbled the memory and caused the crash. Thanks a lot for your help with this. Created commit 97c1584 in eds master (3.19.2+) Created commit 47488ae in eds gnome-3-18 (3.18.3+)
I just applied this fix to debian package and rebuilt it. I cannot reproduce the problem any more. Thank you very much.
Nice, thanks a lot for the confirmation.
Downstream bug report about the same: https://bugzilla.redhat.com/show_bug.cgi?id=1281331
*** Bug 758836 has been marked as a duplicate of this bug. ***
*** Bug 759101 has been marked as a duplicate of this bug. ***
I reopened bug #759101 for one case where a similar backtrace could be shown, but the circumstances of the crash were very different.