[xcb] Unknown sequence number while processing queue SIGABRT about berry

[BartolomeyKant]

Yes, it's working

[JLErvin]

This is a curious issue since berry uses the xlib library, not xcb. Still, it could be something on our end - although I'm more convinced it's some difficult to track down race condition.

Could you post your log file/try to recreate the error so I can do some more thorough investigation?

[dylanaraps]

On my machine libX11 (xlib) depends on libxcb (I'm not sure if this is always the case). I've come across this issue too and I was also unable to fix it.

The steps to reproduce it on my machine are simply:

• Compile berry (make)
• Launch berry.
• Above error.

I'm running with musl libc for reference.

[dylanaraps]

libX11 always requires libxcb:

# Always required
X11_REQUIRES='xproto >= 7.0.17 xextproto xtrans xcb >= 1.11.1'
X11_EXTRA_DEPS="xcb >= 1.11.1"

From: https://github.com/mirror/libX11/blob/master/configure.ac#L80-L82

[JLErvin]

Yes that's true - I just meant that there is no explicit xcb code used inside of berry.

Nonetheless, I'll setup a VM with some musl-based distro and try to debug this.

[dylanaraps]

Note: I'm unsure if @onodera-punpun is using musl also. This may be reproducible on glibc too.

[dylanaraps]

Not sure if this is of any use to you as it's related to a rust library, however it looks like the same issue: rust-windowing/winit#458

The fix is described as:

Fixed race conditions when creating an EventsLoop on X11, most commonly manifesting as "[xcb] Unknown sequence number while processing queue".

[JLErvin]

@dylanaraps I saw that as well but I'm not sure if it's applicable to our problem yet.

[dylanaraps]

Found the error message in libX11: https://github.com/mirror/libX11/blob/823a0f8a820247b6c1e092f679b49cbdc2ea5c95/src/xcb_io.c#L33-L38

[CamilleScholtz]

I'm using glibc, although I do use a source distro, so it could possible be the result of a CFLAG or kernel option I set. However I never saw this error before with any other wm or X app.

[JLErvin]

@onodera-punpun I've haven't seen this issue elsewhere either. Can you post your USE flags (or equivalent) so I can try to recreate the issue on my end?

[CamilleScholtz]

Oh wait, I didn't build this package with my package manager, so in fact I just used the default CFLAGS as defined in config.mk...

[JLErvin]

I added a potential fix. Since I still haven't been able to recreate this on my end could someone try the development branch, raspberry, and see if this fixes the issue? @onodera-punpun

[CamilleScholtz]

Sadly didn't fix the issue, exact same error

[polzon]

I'm on debian 10 stable, and also am getting the same error when I run startx /usr/local/bin/berry

edit: still get the same error on the raspberry branch.

The xorg server will start, and I'll be able to see a blank desktop, but as soon as I left or right click it will crash back to console and give me OP's same error.

Also just tested it on my desktop which runs a near-fresh install of Debian 10 and it doesn't seem to have this issue.

[JLErvin]

@dylanaraps can you post your global compiler options for KISS?

[BartolomeyKant]

I have the same issue on Void Linux. I install berry from void linux repository. Also i tried build from sources.
in my ~/.xinintrc i add

berry &
exec xterm

so after startx i have black screen with xterm but berry not working. If i restart berry from terminal with -d option it says same errors like @onodera-punpun posted.

[BartolomeyKant]

I trying to debug this error.
berry_log.txt

Testing on manjaro, berry builded from source.
At start there is no errors (line 14). But on first event (mouse click or start new application) it crushes (after line 14).

[BartolomeyKant]

I think I know how to repeate this.
I add x permission to .config/berry/autostart and now it working
if I remove x permission it's not working with same error

[JLErvin]

@Notevill yes! oh my goodness thank you I've been unable to recreate this for months. For now, make it executable and I'll try to find a more universal fix :)

[JLErvin]

@Notevill can you try using the development branch, grape, and see if this works without autostart being executable. branch here