Bug 351027 – Crashed when changing folders in the mailer

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 351027 - Crashed when changing folders in the mailer


Summary:	Crashed when changing folders in the mailer


Status:	RESOLVED NOTGNOME

Product:	evolution-data-server
Classification:	Platform
Component:	Mailer
Version:	1.8.x (obsolete)
Hardware:	Other Linux

Importance:	Normal critical
Target Milestone:	---
Assigned To:	evolution-mail-maintainers
QA Contact:	Evolution QA team

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2006-08-12 11:08 UTC by Kjartan Maraas
Modified:	2013-09-14 16:49 UTC

See Also:
GNOME target:	---
GNOME version:	2.15/2.16

Description Kjartan Maraas 2006-08-12 11:08:29 UTC

Memory status: size: 441614336 vsize: 0 resident: 441614336 share: 0 rss: 183721984 rss_rlim: 0
CPU usage: start_time: 1155377223 rtime: 0 utime: 19495 stime: 0 cutime:14879 cstime: 0 timeout: 4616 it_real_value: 0 frequency: 5

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 -1209178416 (LWP 15767)]
[New Thread -1448084576 (LWP 16021)]
[New Thread -1380988000 (LWP 16018)]
[New Thread -1363154016 (LWP 15855)]
[New Thread -1352664160 (LWP 15854)]
[New Thread -1282942048 (LWP 15821)]
[New Thread -1272452192 (LWP 15820)]
[New Thread -1261962336 (LWP 15816)]
0xb7f09402 in __kernel_vsyscall ()

+ Trace 70295

Thread 5 (Thread -1352664160 (LWP 15854))

#0 __kernel_vsyscall
#1 ??
from /lib/libpthread.so.0
#2 libgnomeui_segv_handle
at gnome-ui-init.c line 867
#3 <signal handler called>
#4 __kernel_vsyscall
#5 *__GI_raise
at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
#6 *__GI_abort
at abort.c line 88
#7 IA__g_logv
at gmessages.c line 497
#8 IA__g_log
at gmessages.c line 517
#9 IA__g_realloc
at gmem.c line 172
#10 g_ptr_array_maybe_expand
at garray.c line 414
#11 IA__g_ptr_array_add
at garray.c line 576
#12 search_match_all
at camel-folder-search.c line 705
#13 e_sexp_term_eval
at e-sexp.c line 700
#14 term_eval_and
at e-sexp.c line 255
#15 e_sexp_term_eval
at e-sexp.c line 700
#16 e_sexp_eval
at e-sexp.c line 1304
#17 camel_folder_search_search
#18 local_search_by_expression
#19 camel_folder_search_by_expression
#20 regen_list_regen
at message-list.c line 3675
#21 mail_msg_received
at mail-mt.c line 570
#22 thread_dispatch
at e-msgport.c line 987
#23 start_thread
at pthread_create.c line 274
#24 ??
from /lib/libc.so.6

#0  0xb7f09

Comment 1 André Klapper 2006-08-12 14:36:38 UTC

looks like gtkhtml

Comment 2 Kjartan Maraas 2006-08-12 16:47:42 UTC

I think this happened from two different points in gtkhtml so it could be a gdk/gtk+ problem I reckon. Here's the other trace I got:

+ Trace 70311

#0 __kernel_vsyscall
#1 *__GI___poll
at ../sysdeps/unix/sysv/linux/poll.c line 87
#2 _XWaitForReadable
at XlibInt.c line 498
#3 _XRead
at XlibInt.c line 1087
#4 _XReply
at XlibInt.c line 1714
#5 XQueryPointer
at QuPntr.c line 46
#6 _gdk_windowing_window_get_pointer
at gdkwindow-x11.c line 3520
#7 IA__gdk_window_get_pointer
at gdkwindow.c line 2974
#8 scroll_update_mouse
at gtkhtml.c line 534
#9 IA__g_cclosure_marshal_VOID__VOID

Comment 3 Kjartan Maraas 2006-08-13 00:28:14 UTC

Moving to e-d-s since the real problem seems to be in search_match_all() in camel.

Comment 4 Kjartan Maraas 2006-08-13 10:18:46 UTC

Tried getting more data with valgrind and found these in my log:

==15585== Invalid free() / delete / delete[]
==15585==    at 0x4004FEA: free (vg_replace_malloc.c:233)
==15585==    by 0x5635E2: free_mem (dl-libc.c:235)
==15585==    by 0x563202: __libc_freeres (set-freeres.c:47)
==15585==    by 0x40011F6: _vgnU_freeres (vg_preloaded.c:60)
==15585==    by 0x4E96D3: _Exit (in /lib/libc-2.4.90.so)
==15585==    by 0x8A53A9: g_spawn_async_with_pipes (gspawn.c:584)
==15585==    by 0x8A5449: g_spawn_async (gspawn.c:102)
==15585==    by 0x6A13D3B: gconf_activate_server (gconf-internals.c:3046)
==15585==    by 0x6A1FF51: gconf_get_config_server (gconf.c:2207)
==15585==    by 0x6A20CDA: gconf_engine_connect (gconf.c:324)
==15585==    by 0x6A20F2D: gconf_engine_get_database (gconf.c:399)
==15585==    by 0x6A2263F: gconf_engine_set (gconf.c:1248)
==15585==    by 0x6A2272C: error_checked_set (gconf.c:3321)
==15585==    by 0x6A271D9: gconf_client_set_int (gconf-client.c:1712)
==15585==    by 0x805B134: store_window_size (e-shell-window.c:910)
==15585==    by 0x87A915: g_timeout_dispatch (gmain.c:3420)
==15585==    by 0x87A341: g_main_context_dispatch (gmain.c:2043)
==15585==    by 0x87D31E: g_main_context_iterate (gmain.c:2675)
==15585==    by 0x87D6C8: g_main_loop_run (gmain.c:2879)
==15585==    by 0x6B03A02: bonobo_main (bonobo-main.c:311)
==15585==    by 0x805DB95: main (main.c:614)
==15585==  Address 0x4033350 is not stack'd, malloc'd or (recently) free'd

Though I'm not sure this is related to the other problem.

Comment 5 Kjartan Maraas 2006-08-13 18:39:11 UTC

Could it be something to do with file size/message count? I see gmem.c is bailing out with a message that it can't allocate memory in the trace, and the folder causing it most often is fairly large (170k messages and ~700 MB)

Comment 6 Matthew Barnes 2006-08-21 18:18:27 UTC

We have a new lead on this thanks to Matthias Clasen:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202309#c24

Looks like it's only affecting those using a _very_ recent glibc.

Comment 7 Kjartan Maraas 2006-08-22 18:13:32 UTC

This was confirmed to be a glibc problem.