Bug 981889

Summary: [abrt] claws-mail-3.9.2-1.fc19: g_malloc: malloc(): smallbin double linked list corrupted
Product: [Fedora] Fedora Reporter: Amadeus W.M. <amadeus84>
Component: claws-mailAssignee: Michael Schwendt <bugs.michael>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: amadeus84, andreas.bierfert, bugs.michael
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:b7b46673ba0a5298a780fabede310a3fda4260c3
Fixed In Version: claws-mail-3.9.2-3.fc19 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-23 01:10:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Amadeus W.M. 2013-07-06 18:35:14 UTC
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

Comment 1 Amadeus W.M. 2013-07-06 18:35:17 UTC
Created attachment 769701 [details]
File: backtrace

Comment 2 Amadeus W.M. 2013-07-06 18:35:19 UTC
Created attachment 769702 [details]
File: cgroup

Comment 3 Amadeus W.M. 2013-07-06 18:35:22 UTC
Created attachment 769703 [details]
File: core_backtrace

Comment 4 Amadeus W.M. 2013-07-06 18:35:25 UTC
Created attachment 769704 [details]
File: dso_list

Comment 5 Amadeus W.M. 2013-07-06 18:35:27 UTC
Created attachment 769705 [details]
File: environ

Comment 6 Amadeus W.M. 2013-07-06 18:35:30 UTC
Created attachment 769706 [details]
File: limits

Comment 7 Amadeus W.M. 2013-07-06 18:35:32 UTC
Created attachment 769707 [details]
File: maps

Comment 8 Amadeus W.M. 2013-07-06 18:35:35 UTC
Created attachment 769708 [details]
File: open_fds

Comment 9 Amadeus W.M. 2013-07-06 18:35:37 UTC
Created attachment 769709 [details]
File: proc_pid_status

Comment 10 Amadeus W.M. 2013-07-06 18:35:40 UTC
Created attachment 769710 [details]
File: var_log_messages

Comment 11 Michael Schwendt 2013-07-07 14:37:12 UTC
> #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?

Comment 12 Amadeus W.M. 2013-07-08 02:47:57 UTC
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)

Comment 13 Michael Schwendt 2013-07-08 08:49:45 UTC
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.

Comment 14 Michael Schwendt 2013-07-08 10:55:16 UTC
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

Comment 15 Fedora Update System 2013-07-13 15:47:29 UTC
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

Comment 16 Fedora Update System 2013-07-13 16:08:17 UTC
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

Comment 17 Fedora Update System 2013-07-14 03:28:54 UTC
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).

Comment 18 Fedora Update System 2013-07-23 01:10:09 UTC
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.

Comment 19 Fedora Update System 2013-07-23 01:17:36 UTC
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.