GNOME Bugzilla – Bug 773363
Do not use alloca() in camel-folder-thread.c
Last modified: 2016-10-24 19:34:50 UTC
Created attachment 338273 [details] [review] suggested patch to resolve this crash; use g_new/g_free if temporary array needed in sort_thread is large Overview: When trying to generate a message list, with group by threads on, for a folder with a very large number of threads, evolution crashes Steps to reproduce: 1) Create a mail folder with 100,000+ threads. 2) Choose the group by thread option for viewing that folder 3) Attempt to view the folder. Actual results: The message "Generating message list..." displayed in the message list pane, followed by Evolution crashing variously with a bus error or segmentation fault Expected results: The "Generating message list..." display should eventually be replaced with the message list, grouped by threads Build date & Hardware: 2016-Oct-22 from the 3.22.1 tarball, MacOS Sierra 10.12 Additional information: I interpolate the traceback below. Recompiling with debugging information and running under lldb revealed that the function sort_thread in which the crash occurs uses alloca to create a temporary array of CamelFolderThreadNode * for sorting threads, of length equal to the number of threads. In my case, the length of this array was over 171,000 entries (yes, I have a huge email backlog), and the resulting 1-MB+ alloca blew away my stack, leading to the crash. I have attached a suggested patch in which over some limit (I arbitrarily chose 1,024 entries) sort_thread uses a g_new/g_free pair for the temporary array, to ease the burden on the stack. Recompiling with the attached patch eliminated the crash. In general, it would seem good practice to place some upper bound on the size of objects allocated on the stack, to prevent exceeding the maximum stack size. I hope this patch will aid in resolving this bug report. Backtrace: (lldb) bt * thread #10: tid = 0x192bf0, 0x00000001006b8b24 libcamel-1.2.59.dylib`sort_thread(cp=0x0000700001c83c90) + 196 at camel-folder-thread.c:448, name = 'pool', stop reason = EXC_BAD_ACCESS (code=2, address=0x700001b80000) * frame #0: 0x00000001006b8b24 libcamel-1.2.59.dylib`sort_thread(cp=0x0000700001c83c90) + 196 at camel-folder-thread.c:448 frame #1: 0x00000001006b7e47 libcamel-1.2.59.dylib`thread_summary(thread=0x00000001232cd3d0, summary=0x0000000121ceb520) + 823 at camel-folder-thread.c:579 frame #2: 0x00000001006b7b03 libcamel-1.2.59.dylib`camel_folder_thread_messages_new(folder=0x00000001088b7c90, uids=0x0000000107fb30e0, thread_subject=0) + 355 at camel-folder-thread.c:694 frame #3: 0x000000010fbb22a8 libevolution-mail.dylib`message_list_regen_thread(simple=0x0000000108069b40, source_object=0x000000010b0cef70, cancellable=0x0000000113a7c140) + 952 at message-list.c:5845 frame #4: 0x00000001048b53dc libgio-2.0.0.dylib`run_in_thread + 106 frame #5: 0x00000001048a291a libgio-2.0.0.dylib`io_job_thread + 37 frame #6: 0x00000001048c5879 libgio-2.0.0.dylib`g_task_thread_pool_thread + 248 frame #7: 0x0000000104a72c8c libglib-2.0.0.dylib`g_thread_pool_thread_proxy + 37 frame #8: 0x0000000104a71fee libglib-2.0.0.dylib`g_thread_proxy + 90 frame #9: 0x00007fffb32a9abb libsystem_pthread.dylib`_pthread_body + 180 frame #10: 0x00007fffb32a9a07 libsystem_pthread.dylib`_pthread_start + 286 frame #11: 0x00007fffb32a9231 libsystem_pthread.dylib`thread_start + 13
Oops, I just realized that although the bug manifests in evolution, the bug and associated patch are in evolution-data-server, so I am reclassifying this report to be for the produce evolution-data-server.
Thanks for a bug report and patch. No problem with the Product field, the bugs can be always moved to the right place when the investigation leads to a different Product. I knew I say this somewhere, and it was here: https://bugzilla.redhat.com/show_bug.cgi?id=1319510 Sadly it got stuck meanwhile, thus no fix had been committed so far. I also lost my patch during the time.
Review of attachment 338273 [details] [review]: The patch looks good, I'd just simply allocated on heap always. I'll change it and commit to the sources. Thanks for it.
Created commit bda5a4c in eds master (3.23.2+) Created commit 1bd629d in eds gnome-3-22 (3.22.2+)