Is there any progress on this? Why is it a low priority?
It's seriously irritating!!

I tried the following workaround... I increased my swapfile size from 2Gb to 8Gb. It starts to render now.
Not a bug, def.

As you can see at the end of the dmesg report, the OOM killer killed Blender to free up some memory. So likely the scene is just too heavy for your system.

I attach

1. dmesg after open file in blender
2. dmesg after openfile and rendering it by f12
3. strace blender-3.1.2-linux-x64/blender 2> strace.txt{F13068843}

Does this apply to the specific cursor in edit mode or to all cursors utilized in Blender?

The message from ISL is probably not important. The most likely cause is that the kernel killed Blender due high resource usage, most likely due to insufficient memory.
Do you notice any unusual resource usage when this happens? Can you attach the output of dmesg after Blender is killed?

In T97629#1349378, @poet.poet@gmail.com (poe12) wrote:

(...)

I attach 2 corresponding files.

cycles_debug_log.txt0 BDownload

gpu_debug_log.txt3 KBDownload

(...)

Hmmm, there is nothing relevant in these files.

Please take a look at this for 3.3

✅ For anyone looking for information about the resolution of this bug:

In T90676#1341289, @Peter Eszlari (eszlari) wrote:

In T90676#1216115, @Christian Rauch (christian.rauch) wrote:

However, SDL is a platform abstraction that will not be able to support platform-specific features.

SDL already has some platform-specific features, in v2.0.22 for Wayland too:

https://github.com/libsdl-org/SDL/commit/9c2f46b0d5a5dce636522904fe0afbde78016063

I'm sure, if a popular project like Blender needs more, they would be open to add them.

In T90676#1216115, @Christian Rauch (christian.rauch) wrote:

However, SDL is a platform abstraction that will not be able to support platform-specific features.

As we are not really aligned with releases of those libraries, we will just archive this issue for now, we can always reopen if the issue resurface.
@Tadej Pečar (tpecar) Thank you for your help!

Ok, I've installed libx11-git and rebuilt mesa-git, and yes, this had indeed fixed the issue!

@Tadej Pečar (tpecar) The fix is actually provided by the libx11-git package, which is a make dependency to mesa-git, but as far as I can tell from the log, that was not installed, so maybe my assumption is wrong and this needs to be done manually.
We mainly just want to test the mesa-git when linked against libx11-git, so if you can make sure its the former uses the latter during compilation, that would be the way to do.

Built mesa-git as-is, and Blender 3.1.0 *still* crashes.

Ok, I've updated the system, Blender 3.1.0 with standard system packages still crashes.

I clean-installed Ubuntu 21.10 on another machine. Japanese input does not work with the same error. 2.93.8 and 3.1.0.
xorg version is xorg-server 2:1.20.13-1ubuntu1.1 and unable to upgrade in normal way.

Ok, I have some time to kill, so I went ahead and checked if I can still reproduce the crash on the original system that exhibited this.

@Alexander Ewering (intrr) Okay, no problem. Maybe another user can help with that. @Dennis (blendear) @Tadej Pečar (tpecar) @SpaceOne (SpaceOne) can any of you help test this?

In T90247#1329025, @Omar Emara (OmarSquircleArt) wrote:

It seems a fix was merged into LibX11. @Alexander Ewering (intrr) Can you retest with the latest mesa-git AUR package and see if that fixes the issue?

It seems a fix was merged into LibX11. @Alexander Ewering (intrr) Can you retest with the latest mesa-git AUR package and see if that fixes the issue?

Looks like this was caused by rB89fd3afd1efb: UI: Support pressing Ctrl+F over UI lists to search

Does it mean that the version of xorg required by Blender is very high and will not work on Ubuntu LTS?
I am wondering if this is a problem specific to my env or if it does not work with all popular Linux distributions.

On Xorg 21.1.3 and latest Blender, there is a value in the UTF8 member, I get:

wmEvent type:171/UNKNOWN, val:1/PRESS, prev_type:1/LEFTMOUSE, prev_val:2/RELEASE, modifier={}, keymodifier:0, flag:{}, mouse:(422,218), ascii:'', utf8:'一', pointer:0x7ff06e52a768

This is also reproducible on the CPU when setting the BVH type to BVH2. Seems like BVH2 is randomly corrupted somehow, different runs output different results. I could no reproduce in a debug build, even after multiple tries.

I can confirm this issue. Based on your description of the issue it seems it might be a driver bug on Linux, but I'm not 100% sure. @Patrick Mours (pmoursnv), @Brecht Van Lommel (brecht), or @Kévin Dietrich (kevindietrich) as you able to look at this?

xdotool selectwindow windowactivate click 1 key U4E00

To try to reproduce reliably, I am simulating a key press using xdotool, but I am not able to reproduce the issue. Can you provide the UTF-8 codes for any of the characters you are typing?
Can you also open Blender with --debug-events and check to confirm that the key events corresponds to the keys you intended to enter?

Looks like there is a patch to implement a workaround in XCB https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/113, seems to match the trace mentioned above.

@Harold (hhausman) : fluxbox

@Taschentuch (taschentuch) - very interesting. What window manager are you using?

Blender 3.0.1 (3.0.1+dfsg-7 from Debian sid): same error as above, "blender: ../../src/xcb_io.c:269: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.", after attempt to render via F12. Almost 100% sure crash, if moving around a light before pressing F12. Saving and reopening Blender before pressing F12, almost certain no crash (at least not in this scene). Also Intel gpu, i915.
Hope this helps anyhow.

Everything OK for me as well now.

Build passing on all platforms now:
https://builder.blender.org/admin/#/builders/18/builds/319

LGTM!

Fix warning about missing Imath include directory