GNOME Bugzilla – Bug 352724
Problems when indexing/writing summaries for huge mboxes
Last modified: 2013-09-13 00:49:28 UTC
I've been seeing crashes in various situations lately and some were fixed by a recent glibc update, but I still see some very strange crashes with HEAD and the latest rawhide packages. I ran a jhbuilt version today with MALLOC_PERTURB_ and got this error and backtrace: *** glibc detected *** evolution-2.8: corrupted double-linked list: 0x0f7c72f0 *** ======= Backtrace: ========= /lib/libc.so.6[0x4a4953a] /lib/libc.so.6[0x4a4b61d] /lib/libc.so.6[0x4a4cae3] /lib/libc.so.6(realloc+0xfa)[0x4a4d66a] /opt/gnome2/lib/libglib-2.0.so.0(g_realloc+0x3b)[0x666c33b] /opt/gnome2/lib/libglib-2.0.so.0[0x66471b8] /opt/gnome2/lib/libglib-2.0.so.0(g_ptr_array_add+0x2a)[0x664721a] /opt/gnome2/lib/libedataserver-1.2.so.7[0x1f3494] /opt/gnome2/lib/libglib-2.0.so.0(g_hash_table_foreach+0x56)[0x6658256] /opt/gnome2/lib/libedataserver-1.2.so.7[0x1f4b8d] /opt/gnome2/lib/libedataserver-1.2.so.7(e_sexp_term_eval+0x196)[0x1f3d56] /opt/gnome2/lib/libedataserver-1.2.so.7(e_sexp_eval+0x40)[0x1f3dd0] /opt/gnome2/lib/libcamel-provider-1.2.so.8(camel_folder_search_search+0x192)[0xdbc1f2] /opt/gnome2/lib/evolution-data-server-1.2/camel-providers/libcamellocal.so[0x5f86d89] /opt/gnome2/lib/libcamel-provider-1.2.so.8(camel_folder_search_by_expression+0x4a)[0xdc617a] /opt/gnome2/lib/evolution/2.8/components/libevolution-mail.so[0x1512d8b] /opt/gnome2/lib/evolution/2.8/components/libevolution-mail.so[0x1504a35] /opt/gnome2/lib/libedataserver-1.2.so.7[0x1f20e4] /lib/libpthread.so.0[0xc301b9] /lib/libc.so.6(clone+0x5e)[0x4ab1c2e] Matthias thought this looked like evolution thrashing glibc's malloc data structures. It's been happening every time I start up evolution after selecting the problematic folder, a 1.6 gb mbox file with linux-kernel mailing list archives, so it seems to start just when it's finishing the update of the summary files, but is more reproducable now with this huge folder that has no summary yet. To reproduce I guess it's just a matter of using cat(1) on enough monthly archives to make one of this size.
Created attachment 71546 [details] full backtrace with memory map
Adding to the 2.16.x milestone
FWIW, the glibc bug mentioned is bug 351027 (and http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202309 ).
I get a crash now when I start up evolution. It's fetching mail and saving a folder at the same time and I get this backtrace:
+ Trace 71083
gdb says the stack might be corrupt so the crash could be a symtom of an underlying issue of course...
This is the crash with backtrace from bug-buddy. It's not a crash really, but g_realloc aborting because it can't allocate memory. This is the very same backtrace that was reported as a glibc problem, but I'm running the fixed glibc, so that shouldn't be the problem this time. Memory status: size: 379072512 vsize: 0 resident: 379072512 share: 0 rss: 180854784 rss_rlim: 0 CPU usage: start_time: 1156755735 rtime: 0 utime: 8354 stime: 0 cutime:4655 cstime: 0 timeout: 3699 it_real_value: 0 frequency: 223 Backtrace was generated from '/usr/bin/evolution-2.8' Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1208518960 (LWP 4137)] [New Thread -1366910064 (LWP 4179)] [New Thread -1355801712 (LWP 4175)] [New Thread -1345311856 (LWP 4174)] [New Thread -1334621296 (LWP 4173)] [New Thread -1272673392 (LWP 4148)] [New Thread -1261950064 (LWP 4147)] 0xb7faa402 in __kernel_vsyscall ()
+ Trace 71105
Thread 4 (Thread -1345311856 (LWP 4174))
Turns out this was a glibc bug after all. The first fix they commited didn't cover all cases it seems. Been running for hours without a crash now and I've tried hard to trigger it, but everything seems stable which is good :-) Closing.