It may certainly be something that is not windows specific but just
more likely to crash on windows, and it may be something that is not
dependent on a specific version of SDL but a certain version made it
more likely. However, SDL version and wndows OS make a huge difference
regardless.
I wrote an agressive blit to self testing script that exercises
in-memory surfaces and the screen both
It never crashed or showed weird behavior at all on my Mac ever, and I
ran it a bunch.
On my PC though, it never crashed for SDL 1.2.7 through 1.2.9
For SDL 1.2.10 and 1.2.11 it crashes for me after like 2-6 passes, and
it crashes in the blit from surface to screen
for SDL 1.2.12 and 1.2.13 it crashes immediately on first blit of a
surface to itself, everytime
Also, the way it's exhibiting itself on my machine is definitely a
crash inside SDL's blit (I rebuilt pygame with some prints that prove
it) as opposed to SDL stomping stuff then pygame being messed up when
it returns. It's always a pygame parachute segfault for me as well.
So I really do think that I could get a meaningful crash out of this
if the pygame parachute thing wasn't catching the segfault....
So what is it that makes that pygame parachute thing happen? How do I
turn it off? it seems getting a minidump would be preferrable to
swallowing the error like the parachute thing does....
On Sun, Aug 3, 2008 at 9:22 AM, Lenard Lindstrom <len-l@xxxxxxxxx
<mailto:len-l@xxxxxxxxx>> wrote:
Like previous segfault bugs this one may not be Windows specific.
Windows is just more sensitive to invalid memory accesses. Here's
what happened when I ran the test case interatively:
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32
bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygame
>>> pygame.init()
(6, 0)
>>> a = pygame.Surface((10,10))
>>> a.blit(a, (0, 0))
Fatal Python error: Inconsistent interned string state.
Not a Pygame parachute but a Python integrity check failure. It
all depends on where the surface memory is allocated relative to
everything else. A backtrace of the stack won't help here as the
damage was done before the error was detected. And it is unclear
that the bug is SDL 1.2.13 specific. SDL 1.2.13 may simple
contribute to the conditions that make the bug obvious.