search

kudima / minesweeper

minesweeper with gtk2
Other
4 stars 3 forks source link

xcb_io.c:263: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed #10

Open mia0x75 opened 5 years ago

mia0x75 commented 5 years ago

./miner

[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. miner: xcb_io.c:263: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. Aborted (core dumped)

kudima commented 5 years ago

Can you please give more details regarding the environment and the versions of gtk you used?

mia0x75 commented 5 years ago 
Fedora 30 x64 with 5.1.16 kernel
# rpm -qa | grep gtk2
gtk2-devel-2.24.32-4.fc30.x86_64
adwaita-gtk2-theme-3.28-5.fc30.x86_64
libdbusmenu-gtk2-16.04.0-11.fc30.x86_64
pygtk2-2.24.0-25.fc30.x86_64
webkit2gtk3-plugin-process-gtk2-2.24.3-1.fc30.x86_64
ibus-gtk2-1.5.20-4.fc30.x86_64
gtk2-2.24.32-4.fc30.x86_64
libfm-gtk2-1.3.1-1.fc30.1.x86_64
gtk2-engines-2.20.2-18.fc30.x86_64

Coredump attached. core.2370.gz

kudima commented 5 years ago

I tried to build and run the application on Fedora 30 live cd and was not able to reproduce the issue. Could you please provide the original binary which triggered the core dump attached?

mia0x75 commented 5 years ago

Here it is.

PS. It doesn't happen each time. miner.gz

kudima commented 5 years ago

Can't really get any useful info from the core. Can you provide the output of gdb -q -n -ex bt -batch <path to miner binary> <path to core file> in the environment where you get the crash?

Can you give more details about when the crash happens? Does it crash on start up, during some specific action etc.?

mia0x75 commented 5 years ago 
$ gdb -q -n -ex bt -batch ./miner ./core.18711
[New LWP 18711]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./miner'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007fc28406ee75 in raise () from /lib64/libc.so.6
#0  0x00007fc28406ee75 in raise () at /lib64/libc.so.6
#1  0x00007fc284059895 in abort () at /lib64/libc.so.6
#2  0x00007fc284059769 in _nl_load_domain.cold () at /lib64/libc.so.6
#3  0x00007fc284067566 in annobin_assert.c_end () at /lib64/libc.so.6
#4  0x00007fc283f328db in  () at /lib64/libX11.so.6
#5  0x00007fc283f32980 in  () at /lib64/libX11.so.6
#6  0x00007fc283f32c85 in _XEventsQueued () at /lib64/libX11.so.6
#7  0x00007fc283f24727 in XPending () at /lib64/libX11.so.6
#8  0x00007fc2849ee648 in  () at /lib64/libgdk-x11-2.0.so.0
#9  0x00007fc284392c31 in g_main_context_check () at /lib64/libglib-2.0.so.0
#10 0x00007fc284393182 in  () at /lib64/libglib-2.0.so.0
#11 0x00007fc2843935a3 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#12 0x00007fc284ba6042 in gtk_main () at /lib64/libgtk-x11-2.0.so.0
#13 0x000000000040648d in main (argc=1, argv=0x7ffe3e5634f8) at main.c:709
kudima commented 5 years ago

My best guess is that the assert is related to the fact that the field was drawn outside of gtk expose-event. I've created a new branch _fixdrawing which fixes that. Can you see if you still can reproduce the issue?