Package: xvfb
Version: 2:21.1.21-1
Severity: normal
X-Debbugs-Cc: debian-s390@lists.debian.org, lolando@debian.org
User: debian-s390@lists.debian.org
Usertags: s390x

Hi,

While debugging autopkgtest failures on the napari-console package,
I found out that on s390x they're caused by a reproducible crash in
xvfb.

To reproduce, checkout commit 5e2bdc336376807589c2aef22f3a50229a8ca9b4
of git@salsa.debian.org:python-team/packages/napari-console, remove the
test for s390x in debian/tests/control, and run autopkgtest. You'll find
*.log files for both xvfb and the window manager.

In my case, the xvfb log looked like the following:

(EE)
(EE) Backtrace:
(EE) 0: /usr/bin/Xvfb (xorg_backtrace+0x5a) [0x2aa1a9ad402]
(EE) 1: /usr/bin/Xvfb (0x2aa1a800000+0x1b18ea) [0x2aa1a9b18ea]
(EE) 2: linux-vdso64.so.1 (__kernel_rt_sigreturn+0x0) [0x3ffd84fe4e0]
(EE) 3: /usr/bin/Xvfb (CreatePicture+0x9e) [0x2aa1a8d1df6]
(EE) 4: /usr/bin/Xvfb (0x2aa1a800000+0x138634) [0x2aa1a938634]
(EE) 5: /usr/bin/Xvfb (0x2aa1a800000+0x139852) [0x2aa1a939852]
(EE) 6: /usr/bin/Xvfb (0x2aa1a800000+0x13779c) [0x2aa1a93779c]
(EE) 7: /usr/bin/Xvfb (0x2aa1a800000+0x180a8a) [0x2aa1a980a8a]
(EE) 8: /usr/bin/Xvfb (MapWindow+0x130) [0x2aa1a9838d8]
(EE) 9: /usr/bin/Xvfb (0x2aa1a800000+0x1491e8) [0x2aa1a9491e8]
(EE) 10: /usr/bin/Xvfb (0x2aa1a800000+0x14ff68) [0x2aa1a94ff68]
(EE) 11: /usr/bin/Xvfb (0x2aa1a800000+0x154aca) [0x2aa1a954aca]
(EE) 12: /usr/lib/s390x-linux-gnu/libc.so.6 (0x3ffa7700000+0x2ccba) [0x3ffa772ccba]
(EE) 13: /usr/lib/s390x-linux-gnu/libc.so.6 (__libc_start_main+0xa8) [0x3ffa772cdb0]
(EE) 14: /usr/bin/Xvfb (0x2aa1a800000+0x445b8) [0x2aa1a8445b8]
(EE)
(EE) Segmentation fault at address 0x0
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)

I'm disabling the tests on that architecture for now since I have no
idea how to proceed, but I'll gladly help test any suggested fix :-)

Roland.

Hi Roland,

I was just looking into this issue recently.
I can see that the visual masks are hardcoded.
The following patch seems to fix the issue:

diff --git a/hw/vfb/InitOutput.c b/hw/vfb/InitOutput.c
index c8ae0adc9..226536d0d 100644
--- a/hw/vfb/InitOutput.c
+++ b/hw/vfb/InitOutput.c
@@ -1006,10 +1006,17 @@ vfbScreenInit(ScreenPtr pScreen, int argc, char **argv)
                                  8, TrueColor, 0xf800, 0x07e0, 0x001f);
         break;
     case 24:
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+        miSetVisualTypesAndMasks(24,
+                                 ((1 << TrueColor) |
+                                  (1 << DirectColor)),
+                                 8, TrueColor, 0x0000ff00, 0x00ff0000, 0xff000000);
+#else
         miSetVisualTypesAndMasks(24,
                                  ((1 << TrueColor) |
                                   (1 << DirectColor)),
                                  8, TrueColor, 0xff0000, 0x00ff00, 0x0000ff);
+#endif
         break;
     case 30:
         miSetVisualTypesAndMasks(30,


But I haven't tested this thoroughly yet. I will raise a Merge Request with this upstream
and will notify you afterwards. I just wanted to let you know that I was looking into this and
had an update on this.

Thanks,
Pranav

Hi,

(gdb) bt
#0  PictureMatchVisual (pScreen=0x2aa0038dd10, depth=24, pVisual=0x2aa00434610) at ../render/picture.c:501
#1  0x000002aa001491e2 in PictureWindowFormat (pWindow=0x2aa00772520) at ../render/picture.c:62
#2  0x000002aa0010f490 in compNewPixmap (pWin=0x2aa00772520, x=3, y=37, w=1274, h=984) at ../composite/compalloc.c:576
#3  0x000002aa0010f6f4 in compAllocPixmap (pWin=0x2aa00772520) at ../composite/compalloc.c:617
#4  0x000002aa0010b2d2 in compCheckRedirect (pWin=0x2aa00772520) at ../composite/compwindow.c:174
#5  0x000002aa0010b7ee in compRealizeWindow (pWin=0x2aa00772520) at ../composite/compwindow.c:274
#6  0x000002aa000ff074 in RealizeTree (pWin=0x2aa00798df0) at ../dix/window.c:2606
#7  0x000002aa000ff438 in MapWindow (pWin=0x2aa00798df0, client=0x2aa00386600) at ../dix/window.c:2683
#8  0x000002aa00098116 in ProcMapWindow (client=0x2aa00386600) at ../dix/dispatch.c:915
#9  0x000002aa00096ca0 in Dispatch () at ../dix/dispatch.c:553
#10 0x000002aa000aa016 in dix_main (argc=2, argv=0x3ffffff82c8, envp=0x3ffffff82e0) at ../dix/main.c:274
#11 0x000002aa00032aa0 in main (argc=2, argv=0x3ffffff82c8, envp=0x3ffffff82e0) at ../dix/stubmain.c:34

In this backtrace when the execution is at PictureMatchVisual, the visuals in pScreen (pScreen->visuals) is loaded from miInitVisuals (whereas the red, blue and green masks which is getting set in this function is getting set through the miSetVisualTypesAndMasks). As for pVisual, which is fetched through the WindowGetVisual function which in turn loops through configs loaded from mesa (are actually taken from pGlxScreen->fbconfigs which are filled up in __glXDRIscreenProbe which is eventually received from the drilIndexConfigAttrib API) After spending some time reading u_format_table.c, u_format.h and dril_target.c fbconfigs loaded from the mesa library(using drilIndexConfigAttrib) looks very much fine. From what I read and understood, this part seems wrong. And in that case, from what I can understand, miSetVisualTypesAndMasks should not be setting hard coded values (which could be different for big endian machines).
I am pretty new to the code base as well as to the entire concept of graphics. These are the things that I understood by going through the code and running the debugger a few times. I am kind of stuck in this and some feedback will be of immense value.

Thanks,
Pranav

Hi,

I still haven't abandoned this yet.
I can see that disabling composite does lead to passing test
cases.

/usr/bin/Xvfb :99 -extension Composite

Just thought of updating.

Thanks,
Pranav