Hide Forgot
Version-Release number of selected component: evolution-3.18.5.1-1.fc23 Additional info: reporter: libreport-2.6.4 backtrace_rating: 3 cmdline: /usr/bin/evolution crash_function: sort_thread executable: /usr/bin/evolution global_pid: 30174 kernel: 4.4.3-300.fc23.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (8 frames) #0 sort_thread at camel-folder-thread.c:448 #2 thread_summary at camel-folder-thread.c:579 #3 camel_folder_thread_messages_new at camel-folder-thread.c:694 #4 message_list_regen_thread #5 run_in_thread at gsimpleasyncresult.c:898 #6 io_job_thread at gioscheduler.c:85 #7 g_task_thread_pool_thread at gtask.c:1287 #9 g_thread_proxy at gthread.c:778
Created attachment 1138360 [details] File: backtrace
Created attachment 1138361 [details] File: cgroup
Created attachment 1138362 [details] File: core_backtrace
Created attachment 1138363 [details] File: dso_list
Created attachment 1138364 [details] File: environ
Created attachment 1138365 [details] File: exploitable
Created attachment 1138366 [details] File: limits
Created attachment 1138367 [details] File: maps
Created attachment 1138368 [details] File: mountinfo
Created attachment 1138369 [details] File: namespaces
Created attachment 1138370 [details] File: open_fds
Created attachment 1138371 [details] File: proc_pid_status
Created attachment 1138372 [details] File: var_log_messages
Thanks for a bug report. I see from the backtrace where the crash happened, but I do not know why. By any chance, do you have any reproducer for the crash, please?
Similar problem has been detected: Happened when opening a mail folder reporter: libreport-2.6.4 backtrace_rating: 4 cmdline: evolution crash_function: sort_thread executable: /usr/bin/evolution global_pid: 31061 kernel: 4.4.6-300.fc23.x86_64 package: evolution-3.18.5.2-1.fc23 reason: evolution killed by SIGSEGV runlevel: N 5 type: CCpp uid: 1000
Created attachment 1148071 [details] File: backtrace
I looked into the code briefly and I see that the code near the crash is allocation memory on the stack, instead of the heap (it uses alloca()). Looking into the sizes of your threads I'd guess the stack overflow happened somewhere there. Could you tell me how many messages you've stored in that particular folder, please? The latest backtrace shows 1.566.509 messages at the level 0 and 236.556 messages at one of its children. The previous backtraces shows smaller numbers, 18.011 messages at level 0 and 222.754 messages at one of its children. I do not know whether I aim in the right direction, though.
*** Bug 1344905 has been marked as a duplicate of this bug. ***
Hi Milan. The folder that was causing this had 7.000.000+ messages in it, and I had a folders.db 4GB+ in size, so it took a long time to load. Not sure what You mean by level 0, is that a reference to the folder structure, with INBOX being level 0 ?
Thanks for the update. 7 million messages is quite many. Maybe it's the reason for the stack overflow. I built a test package for you [1], which contains a possible fix, the alloca() is replaced with g_malloc(). Could you install it and give it a try, please? With respect of the "level 0", I meant with that the root nodes in the message list tree, basically the first messages in a conversation, which have no parent. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=14670273
This had been addressed upstream at [1]. The change will be avialable with 3.23.2+ and 3.22.2+. [1] https://bugzilla.gnome.org/show_bug.cgi?id=773363