On 2016-12-15 18:19 +0100, Andreas Boll wrote: > Control: tags -1 moreinfo > > On Thu, Aug 14, 2014 at 08:19:54AM -0400, Daniel Schepler wrote: >> On Thu, Aug 14, 2014 at 4:46 AM, Thorsten Glaser <t...@mirbsd.de> wrote: >> > Package: libgl1-mesa-glx >> > Version: 10.2.5-1 >> > Severity: normal >> > >> > Hi! >> > >> > After crossgrading from i386 to x32, OpenGL applications crash. >> > >> > glxgears from mesa-utils:i386 (8.2.0-1) works, but >> > glxgears from mesa-utils:x32 (8.2.0-1) fails: >> > >> > Program received signal SIGSEGV, Segmentation fault. >> > 0xf76db60b in glLightfv () from /usr/lib/x86_64-linux-gnux32/libGL.so.1 >> > (gdb) bt >> > #0 0xf76db60b in glLightfv () from /usr/lib/x86_64-linux-gnux32/libGL.so.1 >> > #1 0x0040146f in ?? () >> > #2 0xf6aceeea in __libc_start_main (main=<optimized out>, argc=1, >> > argv=<optimized out>, >> > init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, >> > stack_end=0xffffd448) >> > at libc-start.c:287 >> > #3 0x00401cfc in ?? () >> > >> > I've first noticed that in "xlock -nolock -mode cage", >> > which, with debugging information, has: >> > >> > Program terminated with signal SIGSEGV, Segmentation fault. >> > #0 0xf6af524b in glGetBooleanv () from >> > /usr/lib/x86_64-linux-gnux32/libGL.so.1 >> > (gdb) bt >> > #0 0xf6af524b in glGetBooleanv () from >> > /usr/lib/x86_64-linux-gnux32/libGL.so.1 >> > #1 0x0040fcfe in init_GL (mi=mi@entry=0x228bde0) at visgl.c:287 >> > #2 0x004dc6d4 in init_cage (mi=<optimized out>) at cage.c:400 >> > #3 0x0040e462 in call_init_hook (ls=0x823340 <LockProcs+1152>, >> > mi=<optimized out>) at mode.c:1290 >> > #4 0x0040887c in justDisplay (display=0x226e870) at xlock.c:2821 >> > #5 0x0040764f in main (argc=36104304, argv=0x0) at xlock.c:3998 >> > >> > Bugs occur in (first glxgears, then xlock): >> > >> > (gdb) disas >> > Dump of assembler code for function glLightfv: >> > 0xf76db600 <+0>: mov rax,QWORD PTR [rip+0x21b9f1] # >> > 0xf78f6ff8 >> > 0xf76db607 <+7>: mov r11,QWORD PTR fs:[rax] >> > => 0xf76db60b <+11>: jmp QWORD PTR [r11+0x500] >> > >> > (gdb) disas >> > Dump of assembler code for function glGetBooleanv: >> > 0xf6af5240 <+0>: mov rax,QWORD PTR [rip+0x21adb1] # >> > 0xf6d0fff8 >> > 0xf6af5247 <+7>: mov r11,QWORD PTR fs:[rax] >> > => 0xf6af524b <+11>: jmp QWORD PTR [r11+0x810] >> > >> > So this appears to be an indirect function call both times. >> >> Always before, when I needed to hand-patch the mesa sources to get a >> custom build, I would disable the x86_64 assembly altogether. It >> would appear that some more porting of the assembly to x32 is needed >> before it's safe to use. In this case, my guess would be that the >> assembly is indexing into an array of function pointers, which on x32 >> would need to be adjusted to jmpl *(4*index, %reg) or maybe addr32 jmp >> *(4*index, %{reg}d) instead of jmpq *(8*index, %reg). >> -- >> Daniel Schepler > > Could you retest with mesa 13.0.2-3 from sid? > I've disabled assembly usage on x32.
That has apparently helped, but I have just re-enabled asm in git[1], since the bug is supposed to be fixed since Mesa 17.0.0. @Thorsten: would be great if you could test that this actually works. Cheers, Sven 1. https://salsa.debian.org/xorg-team/lib/mesa/commit/69d86fe6c8b1c73ddb652e6a404ec87926857939