Re: [Annoyance] Thread still present after leaving balsa

[Pawel Salek <pawsa0 gmail com>]

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