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.
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 -~----------~----~----~----~------~----~------~--~---
