Bug#947196: mesa: "BadMatch" error on X_ShmPutImage in 24bpp; breaks openscad testsuite
Source: mesa
Version: mesa-19.3.1-2
Severity: important
Dear Maintainer,
Since upload to unstable of mesa 19.3.1-1/19.3.1-2, the openscad testsuite
breaks. This also shows up as a regression on
https://tracker.debian.org/pkg/mesa .
The root cause is the following failure to run openscad in a virtual
framebuffer. To reproduce:
$ xvfb-run -s "-screen 0 800x600x24" openscad /dev/null -o /tmp/1.png
Compiling design (CSG Products normalization)...
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 130 (MIT-SHM)
Minor opcode of failed request: 3 (X_ShmPutImage)
Serial number of failed request: 41
Current serial number in output stream: 42
(This requires that the packages "xvfb" and "openscad" are installed).
Interestingly, it does not fail when using 16 bpp:
$ xvfb-run -s "-screen 0 800x600x16" openscad /dev/null -o /tmp/1.png
Compiling design (CSG Products normalization)...
$ ls -l /tmp/1.png
-rw-r--r-- 1 root root 1948 Dec 21 23:44 /tmp/1.png
At this point I do not know the root cause of the problem (I'm happy to
follow suggested directions for debugging this further). I'm providing here
what information I have currently in case this affects migration of mesa to
testing.
That mesa 19.3.1 is the cause of the regression is based on the regression
shown by debci after upload of 19.3.1-1. It is also suggested by the similar
problem reported here:
https://stackoverflow.com/questions/59323267/x-error-of-failed-request-badmatch-on-x-shmputimage-major-opcode-130-minor
Even assuming mesa 19.3.1-1 introduces the problem, it still needs to be
determined if this is a bug in mesa, or if it is incorrect usage from
openscad code. The smaller example in the stackoverflow link might help
determine this (it shows the similar symptoms).
I can work-around the openscad test failure/regression in debci by changing
it to use 16bpp in the virtual framebuffer; this makes the entire testsuite
pass. But it would be nice to understand the root cause of the issue, in
case this affects also other usage than virtual framebuffer device (eg.
normal interactive use on X server from unstable); hence the initial
"important" severity.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect (systemd-nspawn from buster host)
Reply to: