Re: [Annoyance] Thread still present after leaving balsa



On 07/31/2009 07:03:23 PM, Jean-Luc Coulon (f5ibh) wrote:
[cut]
------quoted attachment "balsa-gdb-session"------


Program received signal SIGSEGV, Segmentation fault.
0x00007fffee986ad0 in ?? () from /lib/libc.so.6
(gdb) bt
#0  0x00007fffee986ad0 in ?? () from /lib/libc.so.6
#1  0x00007fffee988da8 in malloc () from /lib/libc.so.6
#2  0x00007fffe823df7c in ?? () from /usr/lib/libxcb.so.1
#3  0x00007fffe823c9a9 in ?? () from /usr/lib/libxcb.so.1
#4 0x00007fffe823e91c in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
#5  0x00007fffee4235c4 in _XReply () from /usr/lib/libX11.so.6
#6  0x00007fffee417a03 in XSync () from /usr/lib/libX11.so.6
#7 0x00007ffff115d96e in gdk_flush () from /usr/lib/libgdk-x11-2.0.so.0 #8 0x00007ffff14e3bad in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0

This is the (in)fameous xcb deadlock problem - or can it be a heap corruption? One way to find out is to run either:

env MALLOC_CHECK_=2 balsa
or using valgrind.

Thread 2 (Thread 0x7fffe1b67950 (LWP 28674)):
#0  0x00007fffee9d6d36 in poll () from /lib/libc.so.6
#1  0x00000000004de914 in bnio_poll (sio=0x7fffdc001860,
want_read=<value optimized out>, want_write=<value optimized out>, fast=0)
    at siobuf.c:301
#2 0x00000000004deb0a in raw_read (sio=0x7fffdc001860) at siobuf.c:522
#3  bnio_fill (sio=0x7fffdc001860) at siobuf.c:560
#4  0x00000000004dee26 in bnio_read (sio=0x7fffe1b66db0,
    bufp=<value optimized out>, buflen=60000) at siobuf.c:592
#5 0x00000000004dee53 in bnio_getc (sio=0x7fffe1b66db0) at siobuf.c:618 #6 0x00000000004d6331 in imap_cmd_get_tag (handle=0xbec000, lastcmd=7)
    at imap-handle.c:885
#7  imap_cmd_step (handle=0xbec000, lastcmd=7) at imap-handle.c:2002
#8  0x00000000004d6c8c in imap_cmd_exec_cmdno (handle=0xbec000,
    cmd=0x7fffdc081c70 "LIST \"Trash\" \"%\"", ret_cmdno=0x0)
    at imap-handle.c:2087
#9  0x00000000004d16d9 in imap_mbox_list (handle=0xbec000,
    what=<value optimized out>) at imap-commands.c:326

I have recently added a thread lock protecting LIST execution - this is meant specifically to prevent protocol errors in LIST. Are you running with or without that change?


Thread 1 (Thread 0x7ffff7e987f0 (LWP 28666)):
#0  0x00007fffee9847dc in ?? () from /lib/libc.so.6
#1  0x00007fffee9870ee in ?? () from /lib/libc.so.6
#2  0x00007fffee988da8 in malloc () from /lib/libc.so.6
#3  0x00007fffef31848e in g_realloc () from /usr/lib/libglib-2.0.so.0
#4  0x00007fffef332464 in ?? () from /usr/lib/libglib-2.0.so.0
#5 0x00007fffef3335ea in g_string_sized_new () from /usr/lib/libglib-2.0.so.0
#6  0x00007fffef308665 in ?? () from /usr/lib/libglib-2.0.so.0
#7  0x00007fffef309fd9 in ?? () from /usr/lib/libglib-2.0.so.0
#8  0x00007fffef30a178 in g_key_file_set_comment ()
   from /usr/lib/libglib-2.0.so.0
#9 0x000000000049ae97 in lbc_sync (conf=0x7262a0) at libbalsa-conf.c:485
#10 0x000000000049af33 in libbalsa_conf_sync () at libbalsa-conf.c:522
---Type <return> to continue, or q <return> to quit---
#11 0x00007fffef30da9d in g_list_foreach () from /usr/lib/libglib-2.0.so.0 #12 0x0000000000467307 in config_address_books_save () at save-restore.c:1581
#13 config_save () at save-restore.c:1183
#14 0x000000000042b00e in balsa_app_destroy () at balsa-app.c:445
#15 0x000000000045bf4f in balsa_cleanup (argc=<value optimized out>,
    argv=0x7fffffffe498) at main.c:1203
#16 main (argc=<value optimized out>, argv=0x7fffffffe498) at main.c:1152
(gdb)

I have never seen a trace like this. The fact that malloc is involved makes me think it may be thread corruption after all...

Pawel


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]