Bug 491458

Summary: pidgin seg faults when disk is full
Product: [Fedora] Fedora Reporter: Joel Uckelman <uckelman>
Component: nautilus-sendtoAssignee: Bastien Nocera <bnocera>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 10CC: bnocera, stickster, stu, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-09 15:26:52 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:

Description Joel Uckelman 2009-03-21 10:49:30 UTC
Description of problem:

If the partition where the user's home directory is is full, then pidgin will seg fault shortly after start up.


Version-Release number of selected component (if applicable):

pidgin-2.5.5-1.fc10.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Fill your /home partition.
2. Start pidgin.
  
Actual results:

Program received signal SIGSEGV, Segmentation fault.
0x000000357707a435 in free () from /lib64/libc.so.6
(gdb) bt full
#0  0x000000357707a435 in free () from /lib64/libc.so.6
No symbol table info available.
#1  0x00000032bde5b0ca in g_string_free () from /lib64/libglib-2.0.so.0
No symbol table info available.
#2  0x00007ffff1e916c7 in mkdir () from /usr/lib64/pidgin/nautilus.so
No symbol table info available.
#3  0x000000377888c420 in purple_signal_emit_vargs ()
   from /usr/lib64/libpurple.so.0
No symbol table info available.
#4  0x000000377888c682 in purple_signal_emit () from /usr/lib64/libpurple.so.0
No symbol table info available.
#5  0x0000003778843dc9 in purple_blist_update_buddy_status ()
   from /usr/lib64/libpurple.so.0
No symbol table info available.
#6  0x000000377887fba5 in purple_prpl_got_user_status ()
   from /usr/lib64/libpurple.so.0
No symbol table info available.
#7  0x00007fffec241a08 in ?? () from /usr/lib64/purple-2/liboscar.so.0
No symbol table info available.
#8  0x00007fffec21f711 in ?? () from /usr/lib64/purple-2/liboscar.so.0
No symbol table info available.
#9  0x00007fffec230c89 in ?? () from /usr/lib64/purple-2/liboscar.so.0
No symbol table info available.
#10 0x000000000046a52e in ?? ()
No symbol table info available.
#11 0x00000032bde3779b in g_main_context_dispatch ()
   from /lib64/libglib-2.0.so.0
No symbol table info available.
#12 0x00000032bde3af6d in ?? () from /lib64/libglib-2.0.so.0
No symbol table info available.
#13 0x00000032bde3b49d in g_main_loop_run () from /lib64/libglib-2.0.so.0
No symbol table info available.
#14 0x0000003fcf7238a7 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
No symbol table info available.
#15 0x0000000000484a0b in main ()


Expected results:

pidgin should not seg fault. Maybe it should tell you that your disk is full, if what it's trying to do fails.


Additional info:

This isn't a serious problem---the workaround it not to have a completely full disk. However, having pidgin fail is *how* I discovered that I had a completely full disk, and it's not exactly obvious getting from "pidgin seg faults" to "disk is full".

Comment 1 Stu Tomlinson 2009-03-21 17:58:24 UTC
This is a bug in the nautilus integration plugin.

Comment 2 Bastien Nocera 2009-03-30 10:38:50 UTC
There must be corruption in the stack trace because there's no way that mkdir would call g_string_free:

#1  0x00000032bde5b0ca in g_string_free () from /lib64/libglib-2.0.so.0
No symbol table info available.
#2  0x00007ffff1e916c7 in mkdir () from /usr/lib64/pidgin/nautilus.so
No symbol table info available.

Could you please replicate the problem with the debuginfo packages installed, and run pidgin under valgrind to replicate the problem?

Comment 3 Joel Uckelman 2009-04-07 15:08:00 UTC
I filled up my /home partition again, and here's what I get:

[uckelman@scylla ~]$ valgrind pidgin 
==3442== Memcheck, a memory error detector.
==3442== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==3442== Using LibVEX rev 1804, a library for dynamic binary translation.
==3442== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==3442== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==3442== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==3442== For more details, rerun with: -v
==3442== 
==3442== Syscall param write(buf) points to uninitialised byte(s)
==3442==    at 0x3577C0DEA0: __write_nocancel (in /lib64/libpthread-2.9.so)
==3442==    by 0x357BC0996E: _IceTransSocketWrite (Xtranssock.c:2276)
==3442==    by 0x357BC0DBCF: _IceWrite (misc.c:369)
==3442==    by 0x357BC0DCB3: IceFlush (misc.c:82)
==3442==    by 0x4A344F: session_set_value (gtksession.c:236)
==3442==    by 0x4A34EB: session_set_string (gtksession.c:247)
==3442==    by 0x4A3A05: pidgin_session_init (gtksession.c:357)
==3442==    by 0x48492B: main (gtkmain.c:808)
==3442==  Address 0x129de2fc is 12 bytes inside a block of size 1,024 alloc'd
==3442==    at 0x4A05174: calloc (vg_replace_malloc.c:397)
==3442==    by 0x357BC05E59: IceOpenConnection (connect.c:211)
==3442==    by 0x3FDA6027A0: SmcOpenConnection (sm_client.c:135)
==3442==    by 0x4A3994: pidgin_session_init (gtksession.c:332)
==3442==    by 0x48492B: main (gtkmain.c:808)
==3442== 
==3442== Invalid free() / delete / delete[]
==3442==    at 0x4A0609F: free (vg_replace_malloc.c:323)
==3442==    by 0x32BDE5B0C9: g_string_free (gstring.c:473)
==3442==    by 0xB37A6D6: (within /usr/lib64/pidgin/nautilus.so)
==3442==    by 0x377888C41F: purple_signal_emit_vargs (signals.c:482)
==3442==    by 0x377888C681: purple_signal_emit (signals.c:434)
==3442==    by 0x3778843DC8: purple_blist_update_buddy_status (blist.c:795)
==3442==    by 0x377887FBA4: purple_prpl_got_user_status (prpl.c:269)
==3442==    by 0xE5D1E68: yahoo_update_status (yahoo.c:130)
==3442==    by 0xE5D272F: yahoo_process_status (yahoo.c:367)
==3442==    by 0xE5D7850: yahoo_packet_process (yahoo.c:1231)
==3442==    by 0xE5D8E92: yahoo_pending (yahoo.c:2594)
==3442==    by 0x46A52D: pidgin_io_invoke (gtkeventloop.c:78)
==3442==  Address 0x13525f20 is 288 bytes inside a block of size 496 alloc'd
==3442==    at 0x4A04FC0: memalign (vg_replace_malloc.c:460)
==3442==    by 0x4A0507A: posix_memalign (vg_replace_malloc.c:569)
==3442==    by 0x32BDE54A00: slab_allocator_alloc_chunk (gslice.c:1136)
==3442==    by 0x32BDE55BC2: g_slice_alloc (gslice.c:666)
==3442==    by 0x32BE61F699: g_signal_connect_closure (gsignal.c:558)
==3442==    by 0x30F8C6AA63: gtk_accel_label_set_accel_closure (gtkaccellabel.c:482)
==3442==    by 0x32BE60B7DC: g_closure_invoke (gclosure.c:767)
==3442==    by 0x32BE6214BC: signal_emit_unlocked_R (gsignal.c:3244)
==3442==    by 0x32BE622B67: g_signal_emit_valist (gsignal.c:2977)
==3442==    by 0x32BE623092: g_signal_emit (gsignal.c:3034)
==3442==    by 0x30F8E7FEB9: gtk_item_factory_add_item (gtkitemfactory.c:355)
==3442==    by 0x30F8E80499: gtk_item_factory_create_item (gtkitemfactory.c:1122)
==3442== 
==3442== Invalid read of size 1
==3442==    at 0xE5E465C: yahoo_packet_read (yahoo_packet.c:206)
==3442==    by 0xE5D8E51: yahoo_pending (yahoo.c:2582)
==3442==    by 0x46A52D: pidgin_io_invoke (gtkeventloop.c:78)
==3442==    by 0x32BDE3779A: g_main_context_dispatch (gmain.c:2144)
==3442==    by 0x32BDE3AF6C: g_main_context_iterate (gmain.c:2778)
==3442==    by 0x32BDE3B49C: g_main_loop_run (gmain.c:2986)
==3442==    by 0x30F8D238A6: gtk_main (gtkmain.c:1200)
==3442==    by 0x484A0A: main (gtkmain.c:881)
==3442==  Address 0x4cc998a is 0 bytes after a block of size 26 alloc'd
==3442==    at 0x4A0739E: malloc (vg_replace_malloc.c:207)
==3442==    by 0x32BDE3FF62: g_malloc (gmem.c:131)
==3442==    by 0x32BDE57B16: g_memdup (gstrfuncs.c:109)
==3442==    by 0xE5D8E75: yahoo_pending (yahoo.c:2586)
==3442==    by 0x46A52D: pidgin_io_invoke (gtkeventloop.c:78)
==3442==    by 0x32BDE3779A: g_main_context_dispatch (gmain.c:2144)
==3442==    by 0x32BDE3AF6C: g_main_context_iterate (gmain.c:2778)
==3442==    by 0x32BDE3B49C: g_main_loop_run (gmain.c:2986)
==3442==    by 0x30F8D238A6: gtk_main (gtkmain.c:1200)
==3442==    by 0x484A0A: main (gtkmain.c:881)
Pidgin 2.5.5-1.fc10 has segfaulted and attempted to dump a core file.
This is a bug in the software and has happened through
no fault of your own.

If you can reproduce the crash, please notify the developers
by reporting a bug at:
http://developer.pidgin.im/simpleticket/

Please make sure to specify what you were doing at the time
and post the backtrace from the core file.  If you do not know
how to get the backtrace, please read the instructions at
http://developer.pidgin.im/wiki/GetABacktrace
==3442== 
==3442== Invalid read of size 8
==3442==    at 0x32BDE55539: g_slice_alloc (gslice.c:474)
==3442==    by 0x32BDE5B10A: g_string_sized_new (gstring.c:378)
==3442==    by 0x32BDE27EFD: g_build_path_va (gfileutils.c:1314)
==3442==    by 0x32BDE28268: g_build_filename (gfileutils.c:1655)
==3442==    by 0xA1504F6: (within /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so)
==3442==    by 0xA150758: (within /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so)
==3442==    by 0x3577C0F0EF: (within /lib64/libpthread-2.9.so)
==3442==    by 0x3577032F04: raise (raise.c:64)
==3442==    by 0x3577034A72: abort (abort.c:88)
==3442==    by 0x484287: sighandler (gtkmain.c:193)
==3442==    by 0x3577032F8F: (within /lib64/libc-2.9.so)
==3442==    by 0x32BDE35480: g_list_prepend (glist.c:173)
==3442==  Address 0x7000736c65786970 is not stack'd, malloc'd or (recently) free'd
==3442== 
==3442== Process terminating with default action of signal 11 (SIGSEGV)
==3442==  General Protection Fault
==3442==    at 0x32BDE55539: g_slice_alloc (gslice.c:474)
==3442==    by 0x32BDE5B10A: g_string_sized_new (gstring.c:378)
==3442==    by 0x32BDE27EFD: g_build_path_va (gfileutils.c:1314)
==3442==    by 0x32BDE28268: g_build_filename (gfileutils.c:1655)
==3442==    by 0xA1504F6: (within /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so)
==3442==    by 0xA150758: (within /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so)
==3442==    by 0x3577C0F0EF: (within /lib64/libpthread-2.9.so)
==3442==    by 0x3577032F04: raise (raise.c:64)
==3442==    by 0x3577034A72: abort (abort.c:88)
==3442==    by 0x484287: sighandler (gtkmain.c:193)
==3442==    by 0x3577032F8F: (within /lib64/libc-2.9.so)
==3442==    by 0x32BDE35480: g_list_prepend (glist.c:173)
==3442== 
==3442== ERROR SUMMARY: 12 errors from 4 contexts (suppressed: 285 from 1)
==3442== malloc/free: in use at exit: 11,965,129 bytes in 153,671 blocks.
==3442== malloc/free: 456,940 allocs, 303,271 frees, 120,851,321 bytes allocated.
==3442== For counts of detected errors, rerun with: -v
==3442== searching for pointers to 153,671 not-freed blocks.
==3442== checked 12,336,656 bytes.
==3442== 
==3442== LEAK SUMMARY:
==3442==    definitely lost: 322,386 bytes in 6,553 blocks.
==3442==      possibly lost: 288,260 bytes in 274 blocks.
==3442==    still reachable: 11,354,483 bytes in 146,844 blocks.
==3442==         suppressed: 0 bytes in 0 blocks.
==3442== Rerun with --leak-check=full to see details of leaked memory.
Segmentation fault
[uckelman@scylla ~]$ ==3448== 
==3448== ERROR SUMMARY: 8 errors from 1 contexts (suppressed: 285 from 1)
==3448== malloc/free: in use at exit: 11,763,482 bytes in 150,977 blocks.
==3448== malloc/free: 407,227 allocs, 256,250 frees, 98,020,715 bytes allocated.
==3448== For counts of detected errors, rerun with: -v
==3448== searching for pointers to 150,977 not-freed blocks.
==3448== checked 12,232,432 bytes.
==3448== 
==3448== LEAK SUMMARY:
==3448==    definitely lost: 239,680 bytes in 4,820 blocks.
==3448==      possibly lost: 266,084 bytes in 252 blocks.
==3448==    still reachable: 11,257,718 bytes in 145,905 blocks.
==3448==         suppressed: 0 bytes in 0 blocks.
==3448== Rerun with --leak-check=full to see details of leaked memory.
==3447== 
==3447== ERROR SUMMARY: 8 errors from 1 contexts (suppressed: 285 from 1)
==3447== malloc/free: in use at exit: 11,763,316 bytes in 150,973 blocks.
==3447== malloc/free: 407,200 allocs, 256,227 frees, 98,018,013 bytes allocated.
==3447== For counts of detected errors, rerun with: -v
==3447== searching for pointers to 150,973 not-freed blocks.
==3447== checked 12,232,320 bytes.
==3447== 
==3447== LEAK SUMMARY:
==3447==    definitely lost: 239,680 bytes in 4,820 blocks.
==3447==      possibly lost: 266,084 bytes in 252 blocks.
==3447==    still reachable: 11,257,552 bytes in 145,901 blocks.
==3447==         suppressed: 0 bytes in 0 blocks.
==3447== Rerun with --leak-check=full to see details of leaked memory.
==3446== 
==3446== ERROR SUMMARY: 8 errors from 1 contexts (suppressed: 285 from 1)
==3446== malloc/free: in use at exit: 11,763,150 bytes in 150,969 blocks.
==3446== malloc/free: 407,192 allocs, 256,223 frees, 98,017,535 bytes allocated.
==3446== For counts of detected errors, rerun with: -v
==3446== searching for pointers to 150,969 not-freed blocks.
==3446== checked 12,232,208 bytes.
==3446== 
==3446== LEAK SUMMARY:
==3446==    definitely lost: 239,680 bytes in 4,820 blocks.
==3446==      possibly lost: 266,084 bytes in 252 blocks.
==3446==    still reachable: 11,257,386 bytes in 145,897 blocks.
==3446==         suppressed: 0 bytes in 0 blocks.
==3446== Rerun with --leak-check=full to see details of leaked memory.

Comment 4 Bastien Nocera 2009-04-08 12:42:49 UTC
==3442== Invalid free() / delete / delete[]
==3442==    at 0x4A0609F: free (vg_replace_malloc.c:323)
==3442==    by 0x32BDE5B0C9: g_string_free (gstring.c:473)
==3442==    by 0xB37A6D6: (within /usr/lib64/pidgin/nautilus.so)
==3442==    by 0x377888C41F: purple_signal_emit_vargs (signals.c:482)
==3442==    by 0x377888C681: purple_signal_emit (signals.c:434)
==3442==    by 0x3778843DC8: purple_blist_update_buddy_status (blist.c:795)
==3442==    by 0x377887FBA4: purple_prpl_got_user_status (prpl.c:269)
==3442==    by 0xE5D1E68: yahoo_update_status (yahoo.c:130)
==3442==    by 0xE5D272F: yahoo_process_status (yahoo.c:367)
==3442==    by 0xE5D7850: yahoo_packet_process (yahoo.c:1231)
==3442==    by 0xE5D8E92: yahoo_pending (yahoo.c:2594)
==3442==    by 0x46A52D: pidgin_io_invoke (gtkeventloop.c:78)


Stu, is Pidgin multi-threaded? And if so, does it have a guarantee that signals are sent from a particular thread?

Looks to me like the signal was sent from a thread, as opposed to the main thread.  Or could it be the fact that we're not disconnecting the signal on unload?

Comment 5 Stu Tomlinson 2009-04-08 16:57:04 UTC
Pidgin is not multi-threaded. It will also automatically disconnect any purple signals that were connected to when the plugin is unloaded (assuming they were connected using the PurplePlugin as the handle).

Looking at the code, it appears that buddies_str will be repeatedly free'd when unable to save the list to disk:
        if (g_file_set_contents (fd_name, str->str, str->len, &err) == FALSE) {
                purple_debug_info ("nautilus", "couldn't save '%s': %s\n", fd_name, err->message);
                g_error_free (err);
>>>>            g_string_free (buddies_str, TRUE);
        } else {
                purple_debug_info ("nautilus", "saved blist online\n");
            g_string_free (buddies_str, TRUE);
            buddies_str = str;
        }

The line indicated with >>>> should probably be "g_string_free(str, TRUE);" otherwise str is leaked and buddies_str is repeatedly free'd.

Comment 6 Bastien Nocera 2009-04-09 15:26:52 UTC
Should have looked at the code a bit more when checking it out.

Fixed upstream, will be in the next upload for F11.

2009-04-09  Bastien Nocera  <hadess>

        * pidgin_plugin/nautilus-sendto-plugin.c (save_online_buddies):
        Don't crash when writing the buddies list fails (eg. full filesystem),
        spotted by Stu Tomlinson <stu>
        See: https://bugzilla.redhat.com/show_bug.cgi?id=491458