On 01/06/2009, at 5:05 PM, Shawn Krisman <[email protected]>
wrote:
>
> So I compiled a debug version of the glx libraries to really find out
> what was going on. The results where ridiculously strange. First I
> have never seen anything like this in gdb. It looked some of the code
> was just randomly going back a few instructions every once in a while.
> Except not randomly because every time I went through the debugger it
> moved in the same way every time, very very strange. I should also
> note that gdb didn't say anything about switching functions or
> threads. Also important to note is that when it moves back it also
> resets to the state it was before the newer instructions. Well at one
> point in the code the library allocates memory for a glxDrawable
> object but then soon after the code jumps backwards, but to a point
> that the memory isn't allocated .... The pointer comes back as null
> which just happens to be an error condition for the function, then
> glXMakeCurrent registers glXBadDrawable error with xlib and then we
> know the story from there.
Sounds like you had optimisation flags enabled when you compiled the
library.
Alex.
>
>
> So the error handler does not work as expected for sure since the
> glXMakeCurrent definetly caused an xlib error. Also i asked gdb to
> check for all instances of _XError which gives the error to xlib, and
> found about 13 instances of _XError being invoked before
> glXMakeCurrent was even called. The fact that the pyglet error handler
> was never called might have something to do with the asynchronous
> nature of X11 bit it is odd that i've never seen even one of these pop
> up ever.
>
> So I don't really know where to go from here I would definetly like to
> continue debugging, but i'm not really sure what all this gdb
> weirdness is about. I'd also like to say that its a driver issue, but
> pyglet is the only program that i've seen have this error for so far,
> and i've tried several sandbox programs that try to mimic the same
> calls that pyglet makes to glx.
>
> On Sun, May 31, 2009 at 3:02 PM, Alex Holkner
> <[email protected]> wrote:
>>
>> On Mon, Jun 1, 2009 at 12:52 AM, Tristam MacDonald <[email protected]
>> > wrote:
>>> On Sun, May 31, 2009 at 7:56 AM, Shawn Krisman <[email protected]
>>> >
>>> wrote:
>>>>
>>>> Correction switching to mesa 3d libraries without dri
>>>> acceleration and
>>>> glx support will cause this segmentation fault (more specifically
>>>> the
>>>> ubuntu libgl1-mesa-swx11 package.) Without glx and dri, pyglet
>>>> because
>>>> unuseable so this is still a very big bug. I got the newest dri
>>>> enabled libraries and we still have the bug albeit without so many
>>>> segmentation fault issues. So as far as I know the problem stems
>>>> from
>>>> glXMakeCurrent, it returns false. This page shows that there are a
>>>> number of ways this call can fail:
>>>>
>>>> http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/glx/xmakecurrent.html
>>>>
>>>> .
>>>> Unfortunately my belief is that that errors are stored in the same
>>>> queue that is queried by glGetError. This is unfortunate because
>>>> the
>>>> actions of glGetError are undefined until a context is made
>>>> current,
>>>> meaning that there seems to be know way to find out why this device
>>>> context is actually failing.
>>>
>>> The glx errors should be in the Xlib error queue, not the OpenGL
>>> error
>>> queue. Have you tried installing an X error handler?
>>> Instructions on how to do so can be found
>>> here: http://www.motifdeveloper.com/tips/tip29.html
>>
>> pyglet installs an Xlib error handler by default. See
>> pyglet/window/xlib/__init__.py
>>
>> Alex.
>>
>>>
>>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
