Bug 4203 - claws locks up
Summary: claws locks up
Status: RESOLVED INVALID
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: UI (show other bugs)
Version: 3.16.0
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2019-04-24 11:57 UTC by djh
Modified: 2020-10-13 09:09 UTC (History)
1 user (show)

See Also:


Attachments
log of lock up followed by termination (5.61 KB, text/plain)
2019-04-30 12:44 UTC, djh
no flags Details
gdb information from another lockup (4.29 KB, text/plain)
2019-05-02 12:06 UTC, djh
no flags Details
gdb information from another lockup with CTRL-C termination (3.57 KB, text/plain)
2019-05-05 10:16 UTC, djh
no flags Details

Description djh 2019-04-24 11:57:40 UTC
As described on the users list, my copy of claws sometimes locks up (i.e. stops responding to any input, and the display remains fixed). I'm running 3.16.0 and I ran it from a terminal and when it just locked up I saw the output below in
the terminal after I terminated the process (clicked on the X in the window decoration):

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
claws-mail: xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
claws-mail: xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Aborted (core dumped)

(note that whilst it says core dumped, my system is set to not save dumped core)

My copy of claws came from the openSUSE repository for Leap 15.0 but other people have reported apparently similar problems with more recent versions from other sources, so this seems likely to be a claws issue, IMHO. I'm running the LX desktop, FWIW.

These lockups have been occurring for quite a while but are very intermittent and I haven't noticed any particular pattern as to when they occur. I don't experience lockups in other programs.
Comment 1 Paul 2019-04-24 12:11:16 UTC
Please try the latest release, and verify that this is still happening.
Comment 2 Paul 2019-04-24 12:14:32 UTC
also, please provide a backtrace
https://www.claws-mail.org/faq/index.php/Debugging_Claws
Comment 3 Andreas 2019-04-24 12:17:59 UTC
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.
Comment 4 Paul 2019-04-24 12:25:09 UTC
(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?
Comment 5 Andreas 2019-04-24 15:06:21 UTC
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?
Comment 6 djh 2019-04-24 17:18:20 UTC
# 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.
Comment 7 djh 2019-04-30 12:44:22 UTC
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.
Comment 8 djh 2019-05-02 12:06:06 UTC
Created attachment 1978 [details]
gdb information from another lockup

Only two days to another lockup! :) Details attached.
Comment 9 Andrej Kacian 2019-05-02 12:32:33 UTC
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.
Comment 10 Walter Lapchynski 2019-05-05 05:06:45 UTC
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.
Comment 11 djh 2019-05-05 10:16:57 UTC
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?
Comment 12 Walter Lapchynski 2019-05-20 05:13:34 UTC
Actually, that's not true. See the very first post.
Comment 13 djh 2019-05-20 09:51:33 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.