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.
Thanks,
Andreas
Attachment:
signature.asc
Description: Digital signature