Bug#758094: libgl1-mesa-glx:x32: SIGSEGV in OpenGL applications on x32
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 <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
>
> 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
Reply to: