Environment
- Device: Samsung Galaxy S24 Ultra (SM-S928B)
- SoC: Snapdragon 8 Gen 3 (Adreno 750 GPU)
- Android: One UI, kernel 6.1.145-android14-11
- Proroot: v1.2.7 (adaptive static-loader)
- Guest OS: Ubuntu 24.04 LTS (Noble Numbat)
- Desktop: XFCE4 (x11 session)
- Mesa: 26.2.0-devel (git-3743cc80a8) - GPU driver: freedreno/kgsl (OpenGL 4.6, Vulkan 1.3.275)
Bug Description
Under proroot, basic OpenGL rendering works (glxgears achieves 2500–4100 FPS — clearly hardware-accelerated via freedreno). However, Chromium-based browsers' GPU processes crash with exit_code=256 immediately. There's a specific issue with one of the kgsl_pipe_get_param queries (param id 13) that Chromium's EGL/GLES initialization path hits but basic Mesa GLX does not. This suggests the freedreno/kgsl driver partially works through proroot's LD_PRELOAD layer, but a specific ioctl or pipe query fails that Chromium requires for its GPU process startup.
Error Messages
Chromium GPU process crash
[pid:pid] ERROR:content/browser/gpu/gpu_process_host.cc:999] GPU process exited unexpectedly: exit_code=256
[pid:pid] FATAL:content/browser/gpu/gpu_data_manager_impl_private.cc:417] GPU process isn't usable. Goodbye.
xfwm4 compositor crash
x_create_picture_with_pictfmt_and_pixmap ERROR failed to create picture
(X error 8 MATCH request 138 minor 4 serial)
Root Cause
The kgsl_pipe_get_param error with param id 13 is non-fatal for basic Mesa GLX rendering — glxgears. However, Chromium's GPU process initialization uses a different code path that fails when this ioctl returns an error.
Chromium spawns a dedicated GPU process that probes EGL/GLES capabilities via specific Mesa initialization paths. One of these paths calls kgsl_pipe_get_param(pipe, KGSL_PROP_*, &val) with param id 13, which proroot's libc interception layer apparently disrupts — possibly mangling the fd, failing the ioctl translation, or altering the pipe query behavior. The Chromium GPU process treats this as a fatal initialization failure and exits with code 256 (SIGSEGV).
Under standard proot (ptrace-based), all ioctls pass through to the kernel transparently, so Chromium's GPU process starts normally.
What Works
- CPU-bound operations.
- Standard proot's GPU works perfectly (same hardware, same Mesa version)
- Basic OpenGL/Mesa rendering via GLX works at full hardware.
- EGL/GLX initialization succeeds for Mesa's DRI3/KMS path
- Vulkan via
TU_DEBUG=noconform partially works
What Fails
- Chromium's GPU subprocess (exit_code=256 on any EGL/GLES initialization probe)
- xfwm4 built-in compositor (
x_create_picture_with_pictfmt_and_pixmap ERROR)
- picom compositor (same X11 picture creation failure)
- Any application that does GPU initialization through Chromium's subprocess model
What to Investigate
kgsl_pipe_get_param(pipe, 13, &val) — what does param id 13 query? (Likely KGSL_PROP_PHYS_ADDR, KGSL_PROP_GPU_BUSY_PERCENT, or similar GPU property.) This call succeeds in standard proot but fails under proroot with "invalid param id". Is proroot's runtime corrupting the pipe fd or the ioctl data structure?- Does Chromium's EGL initialization use a different fd or pipe path than glxgears? glxgears (GLX) works at full speed, but Chromium (EGL/GLES) crashes. The difference in initialization path is key.
- Does
PROROOT_VERBOSE=1 reveal anything about ioctl interception or fd translation for /dev/dri/* devices?
- Can strace inside proroot (if available) show what ioctl with arg=13 actually does — specifically what fd it's called on and what data is returned?
Test Command
Reproduce with Chromium inside proroot:
brave --no-sandbox --enable-logging --v=1 2>&1 | grep -iE "gpu|egl|kgsl|ioctl|fd"
Environment
Bug Description
Under proroot, basic OpenGL rendering works (glxgears achieves 2500–4100 FPS — clearly hardware-accelerated via freedreno). However, Chromium-based browsers' GPU processes crash with exit_code=256 immediately. There's a specific issue with one of the
kgsl_pipe_get_paramqueries (param id 13) that Chromium's EGL/GLES initialization path hits but basic Mesa GLX does not. This suggests the freedreno/kgsl driver partially works through proroot's LD_PRELOAD layer, but a specific ioctl or pipe query fails that Chromium requires for its GPU process startup.Error Messages
Chromium GPU process crash
xfwm4 compositor crash
Root Cause
The
kgsl_pipe_get_paramerror with param id 13 is non-fatal for basic Mesa GLX rendering — glxgears. However, Chromium's GPU process initialization uses a different code path that fails when this ioctl returns an error.Chromium spawns a dedicated GPU process that probes EGL/GLES capabilities via specific Mesa initialization paths. One of these paths calls
kgsl_pipe_get_param(pipe, KGSL_PROP_*, &val)with param id 13, which proroot's libc interception layer apparently disrupts — possibly mangling the fd, failing the ioctl translation, or altering the pipe query behavior. The Chromium GPU process treats this as a fatal initialization failure and exits with code 256 (SIGSEGV).Under standard proot (ptrace-based), all ioctls pass through to the kernel transparently, so Chromium's GPU process starts normally.
What Works
TU_DEBUG=noconformpartially worksWhat Fails
x_create_picture_with_pictfmt_and_pixmap ERROR)What to Investigate
kgsl_pipe_get_param(pipe, 13, &val)— what does param id 13 query? (LikelyKGSL_PROP_PHYS_ADDR,KGSL_PROP_GPU_BUSY_PERCENT, or similar GPU property.) This call succeeds in standard proot but fails under proroot with "invalid param id". Is proroot's runtime corrupting thepipefd or the ioctl data structure?PROROOT_VERBOSE=1reveal anything about ioctl interception or fd translation for/dev/dri/*devices?Test Command
Reproduce with Chromium inside proroot: