I tried getting a stack trace with gdb for a previous bug. I had no
luck. I think the Python interpreter itself would have to be compiled
with MinGW in debug mode for that to work. The only way I found was the
slow and tedious approach of adding debug print statements. I have
traced the problem to opengltosdl, but no further. Apparently the
parachute isn't tripped until the function returns. Possibly this means
a stack overwrite. I don't know.
Lenard
René Dudfield wrote:
hi,
the gl pygame.image.save(screen) was partially fixed by me the other weekend...
It used to import pyopengl to access its glReadPixels function in
pygame < 1.8.1... however pyopengl 3.x changed the API which broken
the pygame function.
So instead of importing pyopengl for glReadPixels, I used the SDL
function to dynamically load the glReadPixels function... however I've
only tested it on linux, and mac osx. I still haven't set up a
windows environment for compilation yet.
If someone could give me a stack trace with gdb, I might be able to
fix it - otherwise I'll eventually get around to fixing it once I get
mingw set up on my windows machine.
ps. future feature wish for build bot: giving stack traces on segfaults too?
On Tue, Jun 10, 2008 at 2:50 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
I have just confirmed the gl screen save crash has been around since at
least Pygame 1.7.1, so may never have worked on Windows. The
test_subsurface_lock fails should be resolved once Marcus figures out what
lifetime locks are really all about.