Chromium segmentation fault in wl_proxy_set_queue

I’ve a system with kernel 5.4.193 from toradex (toradex_defconfig), running a debian bookworm system, from there two Toradex containers are started:

  • torizon/weston:3.0.8-20230512
  • torizon/chromium:2.7.0-20220825

Weston runs fine, and Chromium without GPU support also runs fine. The moment I try to run Chromium with GPU support (–use-gl=egl --in-process-gpu), Chromium almost immediately crashes:

[4230334.987] xdg_toplevel@30.configure(0, 0, array)
[4230335.081] xdg_surface@29.configure(5)
[4230335.111]  -> xdg_surface@29.set_window_geometry(16, 10, 748, 418)
[4230335.171]  -> xdg_surface@29.ack_configure(5)
[4230336.091] wl_keyboard@7.repeat_info(40, 400)
[4230336.171] wl_keyboard@7.keymap(1, fd 98, 64434)
[Switching to Thread 0xffffc3ffecf0 (LWP 3738)]
0x0000fffff04cc2a4 in wl_proxy_set_queue () from /usr/lib/aarch64-linux-gnu/libwayland-client.so.0

When I google for this specific function wl_proxy_set_queue, I find numerous bugs related to it.

I also have a Yocto based image. Using the exact same two containers, Chromium with GPU support starts properly. So from my perspective it is a software bug, but there seems to be a race condition, so the bug is only triggered under some circumstances.

Maybe someone else also encountered this and has a workaround?

Hi @thomasstauffer !

Happy Toradex Community anniversary! :partying_face: :cake:

Could you please share the output of tdx-info? Please follow the article Getting Device Information with Tdx-Info | Toradex Developer Center to find out how to run it.

From this, I understand that you are using BSP or TorizonCore version 5. Is that right?

The Debian based containers of version Bookworm are maintained for TorizonCore version 6. For TorizonCore 5, you should use Bullseye. Is there a reason for you to use Debian Bookworm based containers on TorizonCore 5?

Best regards,

We started with the BSP 5, therefore 5.4.193. Then had to add a custom touch-screen driver, wich I was too lazy yet to port it 5.15. The reason why we use Debian 12.1 is due to a company wide guideline to base all images we have on 12.1. Therefore I do not use the BSP nor TorizonCore, so far just U-Boot and the Kernel from Toradex.

Since I wrote this post, I found out that if I use the torizon/weston-vivante:3 instead of torizon/weston, chromium does not crash anymore (it does not run into the libwayland-client.so.0 bug anymore). For me this workaround is fine for the moment.

What for me is somehow funny, that on the BSP 5 torizon/weston + torizon/chromium worked, while the same combination does not work anymore on Debian 12.1, despite using the exact same kernel, and in fact only two containers talking to each other. but I also do not think it’s worth to investigate this too much.

tdx-info.txt (24.9 KB)

Hi @thomasstauffer!

Indeed, the torizon/weston-vivante is currently recommended for i.MX8-based modules with GPU, as you can see in the section “How To Choose a Debian Container” from the article Debian Containers for Torizon | Toradex Developer Center. So I would say it is not simply a “workaround”, but the recommended approach :slight_smile:

Also, we have a set of environment variables that helps you to point to the recommended tag of the container, as you can see in the article Torizon Containers Tags and Versioning | Toradex Developer Center.

Btw, could you please mark your last answer as the Solution? :slight_smile:

Thanks!

Have a nice day!

1 Like