[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#722196: marked as done (libGL/libdricore: dispatch table seems off)



Your message dated Thu, 23 Apr 2015 21:05:25 +0200
with message-id <20150423190525.GB20010@inti>
and subject line Re: libGL/libdricore: dispatch table seems off
has caused the Debian Bug report #722196,
regarding libGL/libdricore: dispatch table seems off
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
722196: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722196
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: libgl1-mesa-dri
Version: 9.2-1
Found: 9.1.6-2

Hi,

the dispatcher calls between libGL and libdricore seem to be mismatched.
My sample case is 'Little Inferno', but anyway: the game crashes on startup
directly after a call to glCreateShader(). This is the relevant trace:

] Breakpoint 1, 0xf7fb4250 in glCreateShader () from /usr/lib/i386-linux-gnu/libGL.so.1
] (gdb) disas
] Dump of assembler code for function glCreateShader:
] => 0xf7fb4250 <+0>:     call   0xf7f9e3b1
]    0xf7fb4255 <+5>:     mov    %gs:(%eax),%eax
]    0xf7fb4258 <+8>:     jmp    *0x790(%eax)
]    0xf7fb425e <+14>:    xchg   %ax,%ax
] End of assembler dump.
] [[ stepping through the get-current-pc code... ]]
] (gdb) ni
] 1: x/5i $pc
] => 0xf7fb4255 <glCreateShader+5>:       mov    %gs:(%eax),%eax
]    0xf7fb4258 <glCreateShader+8>:       jmp    *0x790(%eax)
]    0xf7fb425e <glCreateShader+14>:      xchg   %ax,%ax
]    0xf7fb4260 <glDeleteProgram>:        call   0xf7f9e3b1
]    0xf7fb4265 <glDeleteProgram+5>:      mov    %gs:(%eax),%eax
] (gdb) p $eax
] $1 = -92
] (gdb) ni
] 1: x/5i $pc
] => 0xf7fb4258 <glCreateShader+8>:       jmp    *0x790(%eax)
]    0xf7fb425e <glCreateShader+14>:      xchg   %ax,%ax
]    0xf7fb4260 <glDeleteProgram>:        call   0xf7f9e3b1
]    0xf7fb4265 <glDeleteProgram+5>:      mov    %gs:(%eax),%eax
]    0xf7fb4268 <glDeleteProgram+8>:      jmp    *0x794(%eax)
] (gdb) x/8x $eax
] 0x898c380:      0xf6f417b0      0xf6f41960      0xf6f41ab0      0xf6f41be0
] 0x898c390:      0xf6f41590      0xf6f41650      0xf6f41cb0      0xf6ff28c0
] [[ The first items of the function table... ]]
] (gdb) info symbol 0xf6f417b0
] _mesa_NewList in section .text of /usr/lib/i386-linux-gnu/libdricore9.2.0.so.1
] (gdb) info symbol 0xf6f41960
] _mesa_EndList in section .text of /usr/lib/i386-linux-gnu/libdricore9.2.0.so.1
] (gdb) info symbol 0xf6f41ab0
] _mesa_CallList in section .text of /usr/lib/i386-linux-gnu/libdricore9.2.0.so.1
] (gdb) info symbol 0xf6f41be0
] _mesa_CallLists in section .text of /usr/lib/i386-linux-gnu/libdricore9.2.0.so.1
] [[ And here's our target slot: ]]
] (gdb) x/wx ($eax + 0x790)
] 0x898cb10:      0xf6f16f10
] (gdb) info symbol 0xf6f16f10
] _mesa_VertexAttrib2sv in section .text of /usr/lib/i386-linux-gnu/libdricore9.2.0.so.1

And that is what glCreateShader indeed calls...

] (gdb) ni
] 0xf6f16f10 in _mesa_VertexAttrib2sv () from /usr/lib/i386-linux-gnu/libdricore9.2.0.so.1
] 1: x/5i $pc
] => 0xf6f16f10 <_mesa_VertexAttrib2sv>:  push   %ebx
]    0xf6f16f11 <_mesa_VertexAttrib2sv+1>:        call   0xf6f0b220
]    0xf6f16f16 <_mesa_VertexAttrib2sv+6>:        add    $0x3840ea,%ebx
]    0xf6f16f1c <_mesa_VertexAttrib2sv+12>:       sub    $0x18,%esp
]    0xf6f16f1f <_mesa_VertexAttrib2sv+15>:       mov    0x24(%esp),%eax

... which falls flat on its face just a couple of instructions down the line
by dereferencing a NULL. The correct dispatcher slot would have been:

] (gdb) p _mesa_CreateShader
] $2 = {<text variable, no debug info>} 0xf6fac120 <_mesa_CreateShader>
] (gdb) find/w $eax, $eax + 0x1000, 0xf6fac120
] 0x898c9e8
] 1 pattern found.
] (gdb) p/x 0x898c9e8 - $eax
] $3 = 0x668

The trace is from the current experimental 9.2 package versions, but the bug
exists in unstable, too. (The upgrade to experimental was only a desperate
attempt to get rid of the bug in the first place. ;) )


Best regards,

Jan

--- End Message ---
--- Begin Message ---
Was caused by an outdated rogue libGL.so lying around in /lib32, could not
determine how (or by which package) that ever got there. Not a bug, sorry
for the noise.


Jan

--- End Message ---

Reply to: