FS#40913 - [xlockmore] xmlock crashes when using mouse scrollwheel

Attached to Project: Community Packages
Opened by Steven Honeyman (stevenhoneyman) - Friday, 20 June 2014, 14:09 GMT
Last edited by Sergej Pupykin (sergej) - Monday, 23 June 2014, 11:21 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sergej Pupykin (sergej)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

In the current package (xlockmore 5.43-1), scrolling down to the bottom of the list in "xmlock" using the mousewheel results in the program crashing and producing the following error:

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


Additional info:

This behaviour does not occur if I manually build this from the PKGBUILD, or compile from source directly.
I can only reproduce this with the binary package provided by Arch (tested the x86_64 version).


Steps to reproduce:

1. run xmlock
2. move the cursor over the main list
3. spin the scroll wheel down


This task depends upon

Closed by  Sergej Pupykin (sergej)
Monday, 23 June 2014, 11:21 GMT
Reason for closing:  Fixed
Comment by Sergej Pupykin (sergej) - Monday, 23 June 2014, 10:51 GMT
I can reproduce it but I think it is upstream bug. PKGBUILD does not apply any patches. libX11 assertion fails.

#0 0x00007ffff6cfdd67 in raise () from /usr/lib/libc.so.6
#1 0x00007ffff6cff118 in abort () from /usr/lib/libc.so.6
#2 0x00007ffff6cf6bdd in __assert_fail_base () from /usr/lib/libc.so.6
#3 0x00007ffff6cf6c92 in __assert_fail () from /usr/lib/libc.so.6
#4 0x00007ffff70b9f19 in ?? () from /usr/lib/libX11.so.6
#5 0x00007ffff70b9fcb in ?? () from /usr/lib/libX11.so.6
#6 0x00007ffff70ba2dd in _XEventsQueued () from /usr/lib/libX11.so.6
#7 0x00007ffff70abba0 in XEventsQueued () from /usr/lib/libX11.so.6
#8 0x00007ffff73e71f7 in _XtWaitForSomething () from /usr/lib/libXt.so.6
#9 0x00007ffff73e84eb in XtAppProcessEvent () from /usr/lib/libXt.so.6
#10 0x00007ffff73dd36d in XtAppMainLoop () from /usr/lib/libXt.so.6
#11 0x0000000000401dc5 in ?? ()
#12 0x00007ffff6cea000 in __libc_start_main () from /usr/lib/libc.so.6
#13 0x0000000000401e15 in ?? ()
Comment by Steven Honeyman (stevenhoneyman) - Monday, 23 June 2014, 11:07 GMT
I'm glad you can reproduce it - that means one of my CFLAGS or LDFLAGS is "fixing" the problem; or one of yours is causing it (assuming we're both fully up-to-date Arch Linux, I think that is the only thing that could be producing different results when compiling the exact same PKGBUILD)
Comment by Sergej Pupykin (sergej) - Monday, 23 June 2014, 11:21 GMT
I use extra-*-build scripts, so flags should not be changed. But rebuild helps for me too. May be some changes in libXt/libX11...

Loading...