Description of problem: Had one email account created and configured in claws mail (with many directories and rules) and cicked on "New" to create a second account when claws-mail crashed. l Version-Release number of selected component: claws-mail-3.9.2-1.fc19 Additional info: reporter: libreport-2.1.5 backtrace_rating: 4 cmdline: claws-mail crash_function: g_malloc executable: /usr/bin/claws-mail kernel: 3.9.8-300.fc19.x86_64 runlevel: N 3 uid: 1000 xsession_errors: Truncated backtrace: Thread no. 1 (10 frames) #6 g_malloc at gmem.c:159 #7 g_strdup at gstrfuncs.c:364 #8 gtk_label_set_text at gtklabel.c:1910 #9 g_type_create_instance at gtype.c:1909 #10 g_object_constructor at gobject.c:1855 #13 gtk_menu_item_ensure_label at gtkmenuitem.c:2127 #14 gtk_real_menu_item_set_label at gtkmenuitem.c:1468 #15 object_set_property at gobject.c:1358 #17 g_object_new_valist at gobject.c:1836 #19 gtk_menu_item_new_with_label at gtkmenuitem.c:423
Created attachment 769701 [details] File: backtrace
Created attachment 769702 [details] File: cgroup
Created attachment 769703 [details] File: core_backtrace
Created attachment 769704 [details] File: dso_list
Created attachment 769705 [details] File: environ
Created attachment 769706 [details] File: limits
Created attachment 769707 [details] File: maps
Created attachment 769708 [details] File: open_fds
Created attachment 769709 [details] File: proc_pid_status
Created attachment 769710 [details] File: var_log_messages
> #3 0x000000301667bc17 in malloc_printerr (action=<optimized out>, > str=0x301677dcf8 "malloc(): smallbin double linked list corrupted", > ptr=<optimized out>) at malloc.c:4916 That's glibc memory management discovering corruption during allocation for something needed for GTK+. It can be just a side-effect from a bug completely elsewhere (step #20 in colorlabel.c:406 is last in Claws Mail space). If it's not reproducible, it can be very hard to debug, since e.g. you would need to run within Valgrind more often than not. How stable is your hardware?
It is reproducible on my machine. In claws Configuration -> Create New Account. Now two windows pop up: "Edit accounts" and "Preferences for new account". Cancel "Preferences for new account". Then, in the "Edit accounts" window click on the New button. It crashes every time. My hardware is very stable. I have a Dell Precision pc that I've been using for several good years, with no hardware problems. I guess a bad memory module could cause random crashes, but this is the only one I'm getting and it is reproducible. Perhaps some pointer being accessed after being freed. I can run a memtest. Is this what you're asking for? Perhaps I could run claws in valgrind? In fact I just did, and when I cancel the "Preferences for new account" window and then click on "New" in the "Edit accounts" window the whole thing doesn't crash, but rather the "Preferences for new account" window pops up again (as I think it should). However, in valgrind I do see ==16865== Invalid free() / delete / delete[] / realloc() ==16865== at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==16865== by 0x301864D9AE: g_free (in /usr/lib64/libglib-2.0.so.0.3600.3) ==16865== by 0x509BF0: prefs_set_default (in /usr/bin/claws-mail) ==16865== by 0x4F1490: prefs_account_new (in /usr/bin/claws-mail) ==16865== by 0x4F1E74: prefs_account_open (in /usr/bin/claws-mail) ==16865== by 0x44BF0F: account_add (in /usr/bin/claws-mail) ==16865== by 0x3019A0FC56: ??? (in /usr/lib64/libgobject-2.0.so.0.3600.3) ==16865== by 0x3019A27D86: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.3600.3) ==16865== by 0x3019A28A71: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.3600.3) ==16865== by 0x3028A8F644: ??? (in /usr/lib64/libgtk-x11-2.0.so.0.2400.19) ==16865== by 0x3019A0FC56: ??? (in /usr/lib64/libgobject-2.0.so.0.3600.3) ==16865== by 0x3019A27D86: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.3600.3) ==16865== Address 0xf2c5f10 is 0 bytes inside a block of size 1 free'd ==16865== at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==16865== by 0x301864D9AE: g_free (in /usr/lib64/libglib-2.0.so.0.3600.3) ==16865== by 0x50A37A: prefs_free (in /usr/bin/claws-mail) ==16865== by 0x4F1BD7: prefs_account_free (in /usr/bin/claws-mail) ==16865== by 0x4F1EAC: prefs_account_open (in /usr/bin/claws-mail) ==16865== by 0x44BF0F: account_add (in /usr/bin/claws-mail) ==16865== by 0x3019A0FA27: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.3600.3) ==16865== by 0x3019A20A3C: ??? (in /usr/lib64/libgobject-2.0.so.0.3600.3) ==16865== by 0x3019A28828: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.3600.3) ==16865== by 0x3019A28A71: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.3600.3) ==16865== by 0x3028A7514F: ??? (in /usr/lib64/libgtk-x11-2.0.so.0.2400.19) ==16865== by 0x3019A0FC56: ??? (in /usr/lib64/libgobject-2.0.so.0.3600.3) ==16865== RemderService==16928== ==16928== HEAP SUMMARY: ==16928== in use at exit: 6,477,511 bytes in 50,411 blocks ==16928== total heap usage: 551,196 allocs, 500,786 frees, 68,732,912 bytes allocated ==16928== RemderService==16865== ==16865== HEAP SUMMARY: ==16865== in use at exit: 5,397,571 bytes in 38,656 blocks ==16865== total heap usage: 662,745 allocs, 624,090 frees, 90,624,421 bytes allocated ==16865== ==16865== LEAK SUMMARY: ==16865== definitely lost: 44,348 bytes in 121 blocks ==16865== indirectly lost: 45,424 bytes in 1,862 blocks ==16865== possibly lost: 2,846,675 bytes in 21,258 blocks ==16865== still reachable: 2,461,124 bytes in 15,415 blocks ==16865== suppressed: 0 bytes in 0 blocks ==16865== Rerun with --leak-check=full to see details of leaked memory ==16865== ==16865== For counts of detected and suppressed errors, rerun with: -v ==16865== Use --track-origins=yes to see where uninitialised values come from ==16865== ERROR SUMMARY: 1295829 errors from 132 contexts (suppressed: 2 from 2)
Yes, it's a double-free that causes the side-effects in the original backtrace. Many thanks for the very good description of how to reproduce it.
I've forwarded this upstream, since the first attempt at finding the cause has not been successfull: http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2957
claws-mail-3.9.2-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/claws-mail-3.9.2-3.fc19
claws-mail-3.9.2-3.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/claws-mail-3.9.2-3.fc18
Package claws-mail-3.9.2-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing claws-mail-3.9.2-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-12959/claws-mail-3.9.2-3.fc19 then log in and leave karma (feedback).
claws-mail-3.9.2-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
claws-mail-3.9.2-3.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.