Nice! I can't immediately see how to get rid of that but i'll look into it.
On Mon, Jun 1, 2009 at 2:47 AM, Alex Holkner <[email protected]> wrote: > > > > 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 -~----------~----~----~----~------~----~------~--~---
