[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] Another blitting surface to itself crash
I believe I have isolated it to the SDL_revcpy reverse string copy
routine. For gcc is is a macro containing inlined assembly code. For VC
it is a pure C function. It is called when an overlapping copy has a
destination identical to or past the source. Here is demonstration in
Python:
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygame
>>> s = pygame.Surface((10,10), 0, 32)
>>> s.blit(s, (0, 0), (2, 0, 6, 6))
<rect(0, 0, 6, 6)>
>>> s.blit(s, (0, 0), (1, 0, 9, 10))
<rect(0, 0, 9, 10)>
>>> s.blit(s, (0, 0))
Fatal Python error: (pygame parachute) Segmentation Fault
The macro form of SDL_revcpy may inadvertently corrupt a register. It
can only be disabled for gcc by altering a header file.
Lenard
Brian Fisher wrote:
I've actually gotten both the interned string thing and a pygame
parachute error in the same run
also, I still think the weird _strdup linkage is a good clue. I
haven't had time to try myself, but I think compiling sdl with mingw
with source modified to not call strdup ever will fix the problem.
On Sun, Aug 17, 2008 at 11:55 PM, Lenard Lindstrom <len-l@xxxxxxxxx
<mailto:len-l@xxxxxxxxx>> wrote:
Thanks Nicholas,
That is kind of interesting, and kind of confusing. Hugo Arts got
a Pygame parachute on XP that was traced to SDL itself. I get a
Fatal Python error, as do you. But unless you use a vintage
Windows system as I do then it would seem the type of error is
independent of Windows version. It behaves as a memory violation,
but where. And it is MinGW specific.
I ran gdb on a small C program that does a self blit. I saw no
place where pointers go astray. The obvious way in which MinGW and
VC code differs is some inline assembly happens with MinGW. But a
test on the inlined assembly code involved with an overlapping
blit showed no problems. I must be making a faulty assumption
somewhere.
Lenard
Nicholas Dudfield wrote:
Lenard,
"Fatal Python error: Inconsistent interned string state."
On Mon, Aug 18, 2008 at 8:17 AM, Lenard Lindstrom
<len-l@xxxxxxxxx <mailto:len-l@xxxxxxxxx>
<mailto:len-l@xxxxxxxxx <mailto:len-l@xxxxxxxxx>>> wrote:
Yes, debug print statements show the crash happens when the SDL
blit funcion SDL_BlitSurface is called. Did you get a Pygame
parachute or a Python interned string violation?
Lenard
Nicholas Dudfield wrote:
Ok, I have been informed there is are PyGame blits not
derived
from SDL, so that explains that.
{pygame_AlphaBlit, pygame_Blit} from clip above looks like
Seems oblivious (sic) now it's pointed out.
On Sat, Aug 16, 2008 at 4:37 PM, Nicholas Dudfield
<ndudfield@xxxxxxxxx <mailto:ndudfield@xxxxxxxxx>
<mailto:ndudfield@xxxxxxxxx <mailto:ndudfield@xxxxxxxxx>>
<mailto:ndudfield@xxxxxxxxx
<mailto:ndudfield@xxxxxxxxx> <mailto:ndudfield@xxxxxxxxx
<mailto:ndudfield@xxxxxxxxx>>>> wrote:
I had a little play with the test_blit_to_self.py:
SDL VERSION:
1.2.13 prebuilts
PYGAME:
Mingw compiled, svn r 1619
OBSERVATIONS:
Unmodified the test wouldn't run at all as noted
earlier.
I don't know if it's any help but I noticed after
commenting out
the "blitting screen to self" section that I could
get the
"blitting surface to self" test and "blitting surface to
screen"
to run the full 100 cycles if I instantiated the Surface
`a` with
pygame.SRCALPHA flags.
Also, if using BLEND_RGB_ADD flags "blitting screen
to self"
worked. Also screen.copy() worked as a source... but eh.
CONCLUSIONS:
s.blit(s, (0,0)) works if SRCALPHA bits set for s
screen.blit(screen, step, None, pygame.BLEND_RGB_ADD)
Is that any help for you guys in debugging?? I have
no C-fu
or I
would have a tinker myself.
--
Lenard Lindstrom
<len-l@xxxxxxxxx <mailto:len-l@xxxxxxxxx>>
--
Lenard Lindstrom
<len-l@xxxxxxxxx>