Bug#758094: libgl1-mesa-glx:x32: SIGSEGV in OpenGL applications on x32
On Thu, Aug 14, 2014 at 4:46 AM, Thorsten Glaser <tg@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
Reply to: