On, Sun Apr 06, 2008, Lenard Lindstrom wrote: > Well it looks like I have another obscure Pygame 1.8 bug to hunt down. I > was trying the PolyPlay 1.3* Walker demo on Windows - PolyPlay\run.bat - > and a couple of seconds after the simulation starts the program segfaults, > which is caught by the Pygame parachute. Right now I have no idea what > caused it. I suspect it is Pygame because PolyPlay doesn't appear to import > any other third party modules except psyco. It still crashes with psyco > disabled. And the segfault happens for both Python 2.4 and 2.5. If anyone > else experiences the same thing please let me know. Besides that the demo cannot be downloaded on my side ("User is not allowed to use direct links."), the other example provided does the same. DRAWPIX32() seems to be the source as Rene tracked it down and after giving it a short glance. My guess is that it does not take the necessary shifts for 24bpp surfaces into account (in fact it does not do any shifts, but assumes the 3 bytes follow up on each other and are aligned properly). The issue already existed in 1.7.1 (at least for me after trying it out) and maybe earlier versions, which dealt correctly with the 24bpp surface creation. If you use a 32bpp surface, anything works well. A quick fix would be to disable AA support on < 32bpp surfaces, a long-term fix would be to rewrite several code portions to take the necessary shifts into account. > > By the way, the fact Pygame automatically loads all modules in its package > makes debugging difficult. It is pointless to examine sys.modules to > determine what aspects of Pygame a program might be using. That's why we were given printf() ;-). Regards Marcus
Attachment:
pgpclpMhOPrZD.pgp
Description: PGP signature