Summary: | claws locks up | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Claws Mail (GTK 2) | Reporter: | djh <claws-bugzilla> | ||||||||
Component: | UI | Assignee: | users | ||||||||
Status: | RESOLVED INVALID | ||||||||||
Severity: | normal | CC: | wxl | ||||||||
Priority: | P3 | ||||||||||
Version: | 3.16.0 | ||||||||||
Hardware: | PC | ||||||||||
OS: | Linux | ||||||||||
Attachments: |
|
Description
djh
2019-04-24 13:57:40 UTC
Please try the latest release, and verify that this is still happening. also, please provide a backtrace https://www.claws-mail.org/faq/index.php/Debugging_Claws I am running the latest release and it happens there too. If I'm not completely wrong it locks only when I select some text and then want to select some other part (observed in message view AND when typing a new message). If I see in the next days another situation where it locks, I'll update it. (In reply to comment #3) > I am running the latest release and it happens there too. > If I'm not completely wrong it locks only when I select some text and then > want to select some other part (observed in message view AND when typing a > new message). If I see in the next days another situation where it locks, > I'll update it. Can you provide the backtrace, then? I got it into a locked situation again, here is the backtrace, while it is blocking any user interaction: (gdb) thread apply all bt Thread 4 (Thread 0x7fb3ab514700 (LWP 15900)): #0 futex_wait_cancelable (private=0, expected=0, futex_word=0x561397b0f1f4) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x561397b0f1a0, cond=0x561397b0f1c8) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x561397b0f1c8, mutex=0x561397b0f1a0) at pthread_cond_wait.c:655 #3 0x00007fb3b6e8b39b in mailsem_internal_wait () from /usr/lib64/libetpan.so.20 #4 0x000056139725c3b1 in ?? () #5 0x00007fb3b79b3458 in start_thread (arg=<optimized out>) at pthread_create.c:486 #6 0x00007fb3b6d8c80f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7fb3abfff700 (LWP 15896)): #0 0x00007fb3b6d80763 in __GI___poll (fds=0x561397efc010, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007fb3b71febe6 in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x00007fb3b71fef72 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0 #3 0x00007fb3b741f846 in ?? () from /usr/lib64/libgio-2.0.so.0 #4 0x00007fb3b7226ef5 in ?? () from /usr/lib64/libglib-2.0.so.0 #5 0x00007fb3b79b3458 in start_thread (arg=<optimized out>) at pthread_create.c:486 #6 0x00007fb3b6d8c80f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x7fb3b0984700 (LWP 15895)): #0 0x00007fb3b6d80763 in __GI___poll (fds=0x561397efcd10, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007fb3b71febe6 in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x00007fb3b71fed0c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #3 0x00007fb3b71fed51 in ?? () from /usr/lib64/libglib-2.0.so.0 #4 0x00007fb3b7226ef5 in ?? () from /usr/lib64/libglib-2.0.so.0 #5 0x00007fb3b79b3458 in start_thread (arg=<optimized out>) at pthread_create.c:486 #6 0x00007fb3b6d8c80f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7fb3b21e4e00 (LWP 15894)): #0 0x00007fb3b6d80763 in __GI___poll (fds=0x561397b0de90, nfds=7, timeout=27525) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007fb3b71febe6 in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x00007fb3b71fef72 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0 #3 0x00007fb3b7fa2837 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0 #4 0x000056139708db6a in main () And this is the backtrace, when it finally raises the abort signal: Thread 1 "claws-mail" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 return ret; (gdb) thread apply all bt Thread 4 (Thread 0x7fb3ab514700 (LWP 15900)): #0 futex_wait_cancelable (private=0, expected=0, futex_word=0x561397b0f1f0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x561397b0f1a0, cond=0x561397b0f1c8) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x561397b0f1c8, mutex=0x561397b0f1a0) at pthread_cond_wait.c:655 #3 0x00007fb3b6e8b39b in mailsem_internal_wait () from /usr/lib64/libetpan.so.20 #4 0x000056139725c3b1 in ?? () #5 0x00007fb3b79b3458 in start_thread (arg=<optimized out>) at pthread_create.c:486 #6 0x00007fb3b6d8c80f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7fb3abfff700 (LWP 15896)): #0 0x00007fb3b6d80763 in __GI___poll (fds=0x561397efc010, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007fb3b71febe6 in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x00007fb3b71fef72 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0 #3 0x00007fb3b741f846 in ?? () from /usr/lib64/libgio-2.0.so.0 #4 0x00007fb3b7226ef5 in ?? () from /usr/lib64/libglib-2.0.so.0 #5 0x00007fb3b79b3458 in start_thread (arg=<optimized out>) at pthread_create.c:486 #6 0x00007fb3b6d8c80f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x7fb3b0984700 (LWP 15895)): #0 0x00007fb3b6d80763 in __GI___poll (fds=0x561397efcd10, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007fb3b71febe6 in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x00007fb3b71fed0c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #3 0x00007fb3b71fed51 in ?? () from /usr/lib64/libglib-2.0.so.0 #4 0x00007fb3b7226ef5 in ?? () from /usr/lib64/libglib-2.0.so.0 #5 0x00007fb3b79b3458 in start_thread (arg=<optimized out>) at pthread_create.c:486 #6 0x00007fb3b6d8c80f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7fb3b21e4e00 (LWP 15894)): #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007fb3b6ca8535 in __GI_abort () at abort.c:79 #2 0x00007fb3b6ca840f in __assert_fail_base (fmt=0x7fb3b6e1cea8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7fb3b6bf47b0 "!xcb_xlib_threads_sequence_lost", file=0x7fb3b6bf4678 "/home/portage/tmp/portage/x11-libs/libX11-1.6.7/work/libX11-1.6.7/src/xcb_io.c", line=263, function=<optimized out>) at assert.c:92 #3 0x00007fb3b6cb67a2 in __GI___assert_fail (assertion=0x7fb3b6bf47b0 "!xcb_xlib_threads_sequence_lost", file=0x7fb3b6bf4678 "/home/portage/tmp/portage/x11-libs/libX11-1.6.7/work/libX11-1.6.7/src/xcb_io.c", line=263, function=0x7fb3b6bf4af0 "poll_for_event") at assert.c:101 #4 0x00007fb3b6b826bb in ?? () from /usr/lib64/libX11.so.6 #5 0x00007fb3b6b82760 in ?? () from /usr/lib64/libX11.so.6 #6 0x00007fb3b6b82a5d in _XEventsQueued () from /usr/lib64/libX11.so.6 #7 0x00007fb3b6b747b7 in XPending () from /usr/lib64/libX11.so.6 #8 0x00007fb3b7e147b5 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #9 0x00007fb3b71fe5c1 in g_main_context_check () from /usr/lib64/libglib-2.0.so.0 #10 0x00007fb3b71feb90 in ?? () from /usr/lib64/libglib-2.0.so.0 #11 0x00007fb3b71fef72 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0 #12 0x00007fb3b7fa2837 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0 #13 0x000056139708db6a in main () I don't know whether the backtrace is useful though for you, since nothing is compiled with debug symbols. Should I recompile something with debug symbols? # xdpyinfo (extract) vendor string: The X.Org Foundation vendor release number: 11906000 X.Org version: 1.19.6 # hwinfo --gfxcard 15: PCI 02.0: 0300 VGA compatible controller (VGA) [Created at pci.386] Unique ID: _Znp.j1zPNNVJiH1 SysFS ID: /devices/pci0000:00/0000:00:02.0 SysFS BusID: 0000:00:02.0 Hardware Class: graphics card Device Name: "Onboard IGD" Model: "Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x0412 "Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller" SubVendor: pci 0x1025 "Acer Incorporated [ALI]" SubDevice: pci 0x0750 Revision: 0x06 Driver: "i915" Driver Modules: "i915" Memory Range: 0xf7800000-0xf7bfffff (rw,non-prefetchable) Memory Range: 0xe0000000-0xefffffff (ro,non-prefetchable) I/O Ports: 0xf000-0xf03f (rw) Memory Range: 0x000c0000-0x000dffff (rw,non-prefetchable,disabled) IRQ: 34 (4839232 events) Module Alias: "pci:v00008086d00000412sv00001025sd00000750bc03sc00i00" Driver Info #0: Driver Status: i915 is active Driver Activation Cmd: "modprobe i915" Config Status: cfg=no, avail=yes, need=no, active=unknown Primary display adapter: #15 Desktop is LX as stated. Created attachment 1977 [details]
log of lock up followed by termination
I finally experienced another lock-up and this time whilst running under gdb. The output is attached.
Created attachment 1978 [details]
gdb information from another lockup
Only two days to another lockup! :) Details attached.
Unfortunately, backtrace from the moment after window manager terminates the program is not very useful. Instead, try hitting Ctrl+C in the console where gdb is running, and printing a backtrace then and there. That will "freeze" Claws Mail in whatever state it currently is, so the backtrace might actually show something interesting. I just wanted to add a note that there's a similar bug in Ubuntu that is affecting PCManFM. It seems there are several other bugs against other packages that all feature the same behavior: crashing with the "Assertion `!xcb_xlib_threads_sequence_lost' failed" error. The other thing they have in common, like Claws: GTK2. There were applications (e.g SpaceFM, LibreOffice) that also had GTK3 support and when compiled with it, worked without problem. https://bugs.launchpad.net/ubuntu/+source/pcmanfm/+bug/1782984 That said, I'm pretty sure GTK2 is to blame, but not sure how to actually solve it or where exactly to look to find the answers. Created attachment 1979 [details]
gdb information from another lockup with CTRL-C termination
Here's another gdb dump; this time following Andrej's incantation. I thought I had posted it when it happened but apparently not :(
Incidentally there seems to be some confusion here. xcb_xlib_threads_sequence_lost does not appear in any of my postings, so I suppose that anybody posting information about that might be discussing a different bug?
Actually, that's not true. See the very first post. You're quite right; apologies. However, I still say that the other reports appear different to mine, so I think that they may be reporting a different bug. It's just a comment though; the devs will have to check to be sure. |