Re: [pygame] Another blitting surface to itself crash
I believe I found the bug. And it was already fixed for SDL 1.3 (I cannot confirm it is also fixed for 1.2.13 in SVN since the site is down.) There should be a licensing requirement to do assembly level programming :-). The optimized reverse blit uses an i386 string move instruction. The direction of the copy is controlled by a register flag. A cleared flag causes a forward copy, the data pointers are incremented. A set flag causes a reverse copy, decrementing data pointers. The flag was set by the SDL copy code, but not cleared afterwards. And the flag doesn't reset itself apparently. So the set flag sat there like an armed bomb until the next string copy instruction was executed. Lenard Lenard Lindstrom wrote: That seems to be it. Try out the modified SDL.dll for Pythons 2.4. and 2.5: http://www3.telus.net/len_l/pygame/SDL-self-blit.zip md5sum: 59a283f9383d6b5512c236d98e39c97b *SDL-self-blit.zip Lenard Lenard Lindstrom wrote: I will. But it will be hand-customized. Lenard Brian Fisher wrote: Hey Lenard, Can you build SDL with mingw in a way that the inlined assembly won't be used? (i.e. so that it uses the same source that VisualC does to build) -- Lenard Lindstrom [EMAIL PROTECTED]
Re: [pygame] Another blitting surface to itself crash
nice work :) By the sounds of it, that flag might be cleared by linux/glibc? That would make sense if it's working ok on linux. On Wed, Aug 20, 2008 at 7:24 AM, Lenard Lindstrom [EMAIL PROTECTED] wrote: I believe I found the bug. And it was already fixed for SDL 1.3 (I cannot confirm it is also fixed for 1.2.13 in SVN since the site is down.) There should be a licensing requirement to do assembly level programming :-). The optimized reverse blit uses an i386 string move instruction. The direction of the copy is controlled by a register flag. A cleared flag causes a forward copy, the data pointers are incremented. A set flag causes a reverse copy, decrementing data pointers. The flag was set by the SDL copy code, but not cleared afterwards. And the flag doesn't reset itself apparently. So the set flag sat there like an armed bomb until the next string copy instruction was executed. Lenard Lenard Lindstrom wrote: That seems to be it. Try out the modified SDL.dll for Pythons 2.4. and 2.5: http://www3.telus.net/len_l/pygame/SDL-self-blit.zip md5sum: 59a283f9383d6b5512c236d98e39c97b *SDL-self-blit.zip Lenard Lenard Lindstrom wrote: I will. But it will be hand-customized. Lenard Brian Fisher wrote: Hey Lenard, Can you build SDL with mingw in a way that the inlined assembly won't be used? (i.e. so that it uses the same source that VisualC does to build) -- Lenard Lindstrom [EMAIL PROTECTED]
Re: [pygame] Another blitting surface to itself crash
Thanks claudio, I should have looked in the SDL bug tracker first, though. However, even knowing what the problem is now I cannot find the related bug report. So it may have been fixed quietly. Lenard claudio canepa wrote: Lenard rulez!!! :-) On 8/19/08, *Lenard Lindstrom* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I believe I found the bug. And it was already fixed for SDL 1.3 (I cannot confirm it is also fixed for 1.2.13 in SVN since the site is down.) There should be a licensing requirement to do assembly level programming :-). The optimized reverse blit uses an i386 string move instruction. The direction of the copy is controlled by a register flag. A cleared flag causes a forward copy, the data pointers are incremented. A set flag causes a reverse copy, decrementing data pointers. The flag was set by the SDL copy code, but not cleared afterwards. And the flag doesn't reset itself apparently. So the set flag sat there like an armed bomb until the next string copy instruction was executed. Lenard Lenard Lindstrom wrote: That seems to be it. Try out the modified SDL.dll for Pythons 2.4. and 2.5: http://www3.telus.net/len_l/pygame/SDL-self-blit.zip md5sum: 59a283f9383d6b5512c236d98e39c97b *SDL-self-blit.zip Lenard Lenard Lindstrom wrote: I will. But it will be hand-customized. Lenard Brian Fisher wrote: Hey Lenard, Can you build SDL with mingw in a way that the inlined assembly won't be used? (i.e. so that it uses the same source that VisualC does to build)
Re: [pygame] Another blitting surface to itself crash
to confirm, looks like it is fixed in SDL 1.2 SVN: http://svn.libsdl.org/branches/SDL-1.2/include/SDL_stdinc.h somebody added a cld after the rep movsl however it is definitely _not_ fixed in 1.2.13 though (you can see from the source archive: http://libsdl.org/release/SDL-1.2.13.zip ) , meaning it won't be fixed until SDL 1.2.14 is released.. On Tue, Aug 19, 2008 at 2:24 PM, Lenard Lindstrom [EMAIL PROTECTED] wrote: I believe I found the bug. And it was already fixed for SDL 1.3 (I cannot confirm it is also fixed for 1.2.13 in SVN since the site is down.) There should be a licensing requirement to do assembly level programming :-). The optimized reverse blit uses an i386 string move instruction. The direction of the copy is controlled by a register flag. A cleared flag causes a forward copy, the data pointers are incremented. A set flag causes a reverse copy, decrementing data pointers. The flag was set by the SDL copy code, but not cleared afterwards. And the flag doesn't reset itself apparently. So the set flag sat there like an armed bomb until the next string copy instruction was executed. Lenard Lenard Lindstrom wrote: That seems to be it. Try out the modified SDL.dll for Pythons 2.4. and 2.5: http://www3.telus.net/len_l/pygame/SDL-self-blit.zip md5sum: 59a283f9383d6b5512c236d98e39c97b *SDL-self-blit.zip Lenard Lenard Lindstrom wrote: I will. But it will be hand-customized. Lenard Brian Fisher wrote: Hey Lenard, Can you build SDL with mingw in a way that the inlined assembly won't be used? (i.e. so that it uses the same source that VisualC does to build) -- Lenard Lindstrom [EMAIL PROTECTED]
Re: [pygame] Another blitting surface to itself crash
sure, maybe we could do a quick 1.8.2 release? I'd like to fix up the various Color bugs too. We can change the trunk around to 1.8.2pre instead of 1.9pre. I'd like to back out a few changes from trunk if we do this. cu, On Wed, Aug 20, 2008 at 9:25 AM, Lenard Lindstrom [EMAIL PROTECTED] wrote: Hi René, It could be glibc makes fewer assumptions that Microsoft's C runtime. When I get a chance to recompile SDL.dll and test it maybe it would be an idea to update the Pygame 1.8.1 installer to include the patched SDL.dll as well as an SDL_mixer.dll that fixes the quit/init bug: http://article.gmane.org/gmane.comp.python.pygame/14947/match=mixer+quit+restart Lenard René Dudfield wrote: nice work :) By the sounds of it, that flag might be cleared by linux/glibc? That would make sense if it's working ok on linux. On Wed, Aug 20, 2008 at 7:24 AM, Lenard Lindstrom [EMAIL PROTECTED] wrote: I believe I found the bug. And it was already fixed for SDL 1.3 (I cannot confirm it is also fixed for 1.2.13 in SVN since the site is down.) There should be a licensing requirement to do assembly level programming :-). The optimized reverse blit uses an i386 string move instruction. The direction of the copy is controlled by a register flag. A cleared flag causes a forward copy, the data pointers are incremented. A set flag causes a reverse copy, decrementing data pointers. The flag was set by the SDL copy code, but not cleared afterwards. And the flag doesn't reset itself apparently. So the set flag sat there like an armed bomb until the next string copy instruction was executed. Lenard Lenard Lindstrom wrote: That seems to be it. Try out the modified SDL.dll for Pythons 2.4. and 2.5: http://www3.telus.net/len_l/pygame/SDL-self-blit.zip md5sum: 59a283f9383d6b5512c236d98e39c97b *SDL-self-blit.zip Lenard Lenard Lindstrom wrote: I will. But it will be hand-customized. Lenard Brian Fisher wrote: Hey Lenard, Can you build SDL with mingw in a way that the inlined assembly won't be used? (i.e. so that it uses the same source that VisualC does to build)
Re: [pygame] Another blitting surface to itself crash
Hi Brian, Well that answers the question when it was fixed. The libsdl SVN viewer is down at the moment so I can't get the message associated with the bug fix. I can't find the associated bug entry in the SDL bug tracker. I would like to know if it was a known issue or just something someone noticed while doing something else. If it had been reported and I had thought to look for it in the bug tracker it could have saved a lot of time. Lenard Brian Fisher wrote: to confirm, looks like it is fixed in SDL 1.2 SVN: http://svn.libsdl.org/branches/SDL-1.2/include/SDL_stdinc.h somebody added a cld after the rep movsl however it is definitely _not_ fixed in 1.2.13 though (you can see from the source archive: http://libsdl.org/release/SDL-1.2.13.zip ) , meaning it won't be fixed until SDL 1.2.14 is released.. On Tue, Aug 19, 2008 at 2:24 PM, Lenard Lindstrom [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I believe I found the bug. And it was already fixed for SDL 1.3 (I cannot confirm it is also fixed for 1.2.13 in SVN since the site is down.) There should be a licensing requirement to do assembly level programming :-). The optimized reverse blit uses an i386 string move instruction. The direction of the copy is controlled by a register flag. A cleared flag causes a forward copy, the data pointers are incremented. A set flag causes a reverse copy, decrementing data pointers. The flag was set by the SDL copy code, but not cleared afterwards. And the flag doesn't reset itself apparently. So the set flag sat there like an armed bomb until the next string copy instruction was executed. Lenard Lenard Lindstrom wrote: That seems to be it. Try out the modified SDL.dll for Pythons 2.4. and 2.5: http://www3.telus.net/len_l/pygame/SDL-self-blit.zip md5sum: 59a283f9383d6b5512c236d98e39c97b *SDL-self-blit.zip Lenard Lenard Lindstrom wrote: I will. But it will be hand-customized. Lenard Brian Fisher wrote: Hey Lenard, Can you build SDL with mingw in a way that the inlined assembly won't be used? (i.e. so that it uses the same source that VisualC does to build)
Re: [pygame] Another blitting surface to itself crash
Greg Ewing wrote: Lenard Lindstrom wrote: The direction of the copy is controlled by a register flag... The flag was set by the SDL copy code, but not cleared afterwards. Blarg. Modes are a bad thing in machine languages as well as user interfaces! Hi Greg, Yes, I wondered why a flag was used instead of distinct reverse copy instructions. Just as a movs instruction is transformed into a string copy by a single byte prefix code rep, the operation could be reversed with an additional prefix. Maybe Intel thought copy code could be reused for both forwards an backwards copies. Or they wanted to keep the byte count down. But since the data pointers have to be set up specifically for copy direction it probably doesn't make much of a difference. -- Lenard Lindstrom [EMAIL PROTECTED]
Re: [pygame] Another blitting surface to itself crash
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 [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] 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
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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
[EMAIL PROTECTED]
Re: [pygame] Another blitting surface to itself crash
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]mailto:
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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
[EMAIL PROTECTED]
Re: [pygame] Another blitting surface to itself crash
maybe it is memory alignment? Maybe the mmx/sse routines require 8
byte alignment or something?
On Mon, Aug 18, 2008 at 4:55 PM, Lenard Lindstrom [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] 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
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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
[EMAIL PROTECTED]
Re: [pygame] Another blitting surface to itself crash
No mmx/sse instructions are used when source and destination are
identical. Just a string move, rep movsl. I isolated the reverse copy
code in a simple C program. It is attached. There is definitely
something wrong, though I don't know yet. It appears to run just fine
unless I redirect output, then it hangs. Comment out SDL_revcpy and it
runs to completion. So something is being stomped.
Lenard
René Dudfield wrote:
maybe it is memory alignment? Maybe the mmx/sse routines require 8
byte alignment or something?
On Mon, Aug 18, 2008 at 4:55 PM, Lenard Lindstrom [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] 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
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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.
#include stdio.h
#include stdlib.h
#define SDL_revcpy(dst, src, len) \
do {\
int u0, u1, u2; \
char *dstp = (char *)(dst); \
char *srcp = (char *)(src); \
int n = (len); \
if ( n = 4 ) { \
__asm__ __volatile__ ( \
std\n\t \
rep ; movsl\n\t \
: =c (u0), =D (u1), =S (u2)\
: 0 (n 2), \
1 (dstp+(n-4)), 2 (srcp+(n-4))\
: memory ); \
} \
switch (n 3) {\
case 3: dstp[2] = srcp[2]; \
case 2: dstp[1] = srcp[1]; \
case 1: dstp[0] = srcp[0]; \
break; \
default:\
break; \
} \
} while(0)
int main(int argc, char *argv[])
{
const int bufsize = 40;
const int padding = 8;
const int blocksize = 20;
char buffer[bufsize+1], *b;
int alignment, dstoffset, i;
buffer[bufsize] = 0; /* null terminated string */
for (alignment = 0; alignment 4; ++alignment)
{
b = buffer + padding + alignment;
for (dstoffset = 0; dstoffset 5; ++dstoffset)
{
for (i = 0; i bufsize; ++i)
{
buffer[i] = '.';
}
for
Re: [pygame] Another blitting surface to itself crash
Hey Lenard, Can you build SDL with mingw in a way that the inlined assembly won't be used? (i.e. so that it uses the same source that VisualC does to build) On Mon, Aug 18, 2008 at 12:28 PM, Lenard Lindstrom [EMAIL PROTECTED] wrote: No mmx/sse instructions are used when source and destination are identical. Just a string move, rep movsl. I isolated the reverse copy code in a simple C program. It is attached. There is definitely something wrong, though I don't know yet. It appears to run just fine unless I redirect output, then it hangs. Comment out SDL_revcpy and it runs to completion. So something is being stomped. Lenard
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 [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] 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
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] 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
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
--
Lenard Lindstrom
[EMAIL PROTECTED]
Re: [pygame] Another blitting surface to itself crash
I will. But it will be hand-customized. Lenard Brian Fisher wrote: Hey Lenard, Can you build SDL with mingw in a way that the inlined assembly won't be used? (i.e. so that it uses the same source that VisualC does to build) On Mon, Aug 18, 2008 at 12:28 PM, Lenard Lindstrom [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: No mmx/sse instructions are used when source and destination are identical. Just a string move, rep movsl. I isolated the reverse copy code in a simple C program. It is attached. There is definitely something wrong, though I don't know yet. It appears to run just fine unless I redirect output, then it hangs. Comment out SDL_revcpy and it runs to completion. So something is being stomped. Lenard -- Lenard Lindstrom [EMAIL PROTECTED]
Re: [pygame] Another blitting surface to itself crash
That seems to be it. Try out the modified SDL.dll for Pythons 2.4. and 2.5: http://www3.telus.net/len_l/pygame/SDL-self-blit.zip md5sum: 59a283f9383d6b5512c236d98e39c97b *SDL-self-blit.zip Lenard Lenard Lindstrom wrote: I will. But it will be hand-customized. Lenard Brian Fisher wrote: Hey Lenard, Can you build SDL with mingw in a way that the inlined assembly won't be used? (i.e. so that it uses the same source that VisualC does to build)
Re: [pygame] Another blitting surface to itself crash
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
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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.
Re: [pygame] Another blitting surface to itself crash
Lenard,
Fatal Python error: Inconsistent interned string state.
On Mon, Aug 18, 2008 at 8:17 AM, Lenard Lindstrom [EMAIL PROTECTED] 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 [EMAIL PROTECTED]mailto:
[EMAIL PROTECTED] 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.
Re: [pygame] Another blitting surface to itself crash
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.
Cheers.
ps... attached modified version of test with use alpha blit changes
pps.
This is in surface.c around line 1996 ??
/* see if we should handle alpha ourselves */
if (dst-format-Amask (dst-flags SDL_SRCALPHA)
!(src-format-Amask !(src-flags SDL_SRCALPHA))
/* special case, SDL works */
(dst-format-BytesPerPixel == 2 || dst-format-BytesPerPixel ==
4))
{
result = pygame_AlphaBlit (src, srcrect, dst, dstrect, the_args);
}
else if (the_args != 0)
{
result = pygame_Blit (src, srcrect, dst, dstrect, the_args);
}
else
{
result = SDL_BlitSurface (src, srcrect, dst, dstrect);
}
import pygame
import random
import math
import sys
print pygame.get_sdl_version()
# pygame.FULLSCREEN#create a fullscreen display
# pygame.DOUBLEBUF #recommended for HWSURFACE or OPENGL
# pygame.HWSURFACE #hardware accelerated, only in FULLSCREEN
# pygame.OPENGL#create an opengl renderable display
# pygame.RESIZABLE #display window should be sizeable
# pygame.NOFRAME #display window will have no border or controls
screen = pygame.display.set_mode((800, 600))
num_runs = 100
scroll_step = 100
for i in xrange(num_runs):
print pass,i
test_width = random.randint(10,400)
test_height = random.randint(10,400)
# An optional special flags is for passing in new in 1.8.0: BLEND_ADD,
# BLEND_SUB, BLEND_MULT, BLEND_MIN, BLEND_MAX new in 1.8.1:
# BLEND_RGBA_ADD, BLEND_RGBA_SUB, BLEND_RGBA_MULT, BLEND_RGBA_MIN,
# BLEND_RGBA_MAX BLEND_RGB_ADD, BLEND_RGB_SUB, BLEND_RGB_MULT,
# BLEND_RGB_MIN, BLEND_RGB_MAX With other special blitting flags
# perhaps added in the future.
a = pygame.Surface((test_width, test_height), pygame.SRCALPHA)
a.fill((random.randint(0,255), random.randint(0,255), random.randint(0,255)))
try:
pygame.draw.line(a, (255,255,255), (0,0), (test_width, test_height), 10)
except:
pass
print blitting surface to self
sys.stdout.flush()
a.blit(a, (random.randint(-test_width, test_width), random.randint(-test_height, test_height)))
angle = (2.0*math.pi*i)/num_runs
step = (math.cos(angle)*scroll_step, math.sin(angle)*scroll_step)
print blitting screen to self
sys.stdout.flush()
screen.blit(screen, step, None, pygame.BLEND_RGB_ADD)
print blitting surface to screen
sys.stdout.flush()
screen.blit(a, (random.randint(-test_width, 800), random.randint(-test_height, 600)))
pygame.event.get()
pygame.display.flip()
Re: [pygame] Another blitting surface to itself crash
On 8/7/08, René Dudfield [EMAIL PROTECTED] wrote: A summary of what has been found out so far: * it doesn't seem to crash on linux/osx. * It never crashed for SDL 1.2.7 through 1.2.9 (but crashes with 1.2.9 build Lenard made) * For SDL 1.2.10 and 1.2.11 it crashes 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 * crashes with windib, and directx drivers. * works with a replacement 1.2.13 SDL.dll built with MSVC by brian. * crashes with assembly disabled. * -O compilation also fails. * 1.2.9 SDL fails for Lenard, built with minGW Err, it crashes with SDL 1.2.7 and pygame 1.7.1 (windows)
Re: [pygame] Another blitting surface to itself crash
Just for completeness, I assume what crashed for you with pygame 1.7.1 (and presumably with SDL 1.2.7) for you was the script you posted here: http://article.gmane.org/gmane.comp.python.pygame/12087 Could you test that same script with pygame 1.8.1 and both with and without the SDL here: http://thorbrian.com/SDL_TestBlitToSelf.zip and let us know your results? On Fri, Aug 8, 2008 at 9:42 AM, claudio canepa [EMAIL PROTECTED] wrote: Err, it crashes with SDL 1.2.7 and pygame 1.7.1 (windows)
Re: [pygame] Another blitting surface to itself crash
No difference. Lenard René Dudfield wrote: could you try compiling that file with less optimisation(just -O maybe), and see if that helps? On Wed, Aug 6, 2008 at 12:09 PM, Lenard Lindstrom [EMAIL PROTECTED] wrote: The rebuilt SDL.dll still fails. The problem is MinGW related. And SDL does have code for blitting a surface to itself. Lenard Lenard Lindstrom wrote: I wonder if it is the hermes blit library or some piece of inlined MMX code. These would not be included in a VC build. I will build SDL with assembly code turned off and see what happens.
Re: [pygame] Another blitting surface to itself crash
Same problem with 1.2.9 Lenard Brian Fisher wrote: As this is a case where the symptom is not connected to the cause (so looking at the crash in a debugger may not help much) but it seems the problem can be reproduced consistently no problem, Maybe this is a good circumstance for binary search debugging? getting and building SDL from different SVN revisions may be a great way to do that. For me, the prebuilt 1.2.9 doesn't crash but the prebuilt 1.2.10 does (although not on the very first blit to self). If MingW built SDL's behave that same way, then one could do a binary search of SDL's built from the revision numbers between the 2 releases to target things down to a specific code change that made it happen. likewise the repro behavior of the bug changed from 1.2.11 to 1.2.12, so a binary search between those revisions may be good to do as well. Another approach other than using SVN revisions is commenting out functionality (so making it so only half of the code needed to do blit to self executes, and seeing if the crash still happpens). Of course that makes blit-to-surface not have the right behavior, and you need to be a careful about how you comment out, but it can often narrow down the problem code to a fairly small set. I'm afraid I can't help with such things at the moment, cause I'm not setup to build with MingW on windows. On Tue, Aug 5, 2008 at 7:09 PM, Lenard Lindstrom [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The rebuilt SDL.dll still fails. The problem is MinGW related. And SDL does have code for blitting a surface to itself. Lenard Lenard Lindstrom wrote: I wonder if it is the hermes blit library or some piece of inlined MMX code. These would not be included in a VC build. I will build SDL with assembly code turned off and see what happens.
Re: [pygame] Another blitting surface to itself crash
Since it's not code changes that made 1.2.10 prebuilt crash, I guess that may mean what changed with 1.2.10 was how the libsdl people make their prebuilts? What about commenting out functionality of the blit to self to try and narrow down the cause? On Thu, Aug 7, 2008 at 2:21 PM, Lenard Lindstrom [EMAIL PROTECTED] wrote: Same problem with 1.2.9 Lenard Brian Fisher wrote: As this is a case where the symptom is not connected to the cause (so looking at the crash in a debugger may not help much) but it seems the problem can be reproduced consistently no problem, Maybe this is a good circumstance for binary search debugging? getting and building SDL from different SVN revisions may be a great way to do that. For me, the prebuilt 1.2.9 doesn't crash but the prebuilt 1.2.10 does (although not on the very first blit to self). If MingW built SDL's behave that same way, then one could do a binary search of SDL's built from the revision numbers between the 2 releases to target things down to a specific code change that made it happen. likewise the repro behavior of the bug changed from 1.2.11 to 1.2.12, so a binary search between those revisions may be good to do as well. Another approach other than using SVN revisions is commenting out functionality (so making it so only half of the code needed to do blit to self executes, and seeing if the crash still happpens). Of course that makes blit-to-surface not have the right behavior, and you need to be a careful about how you comment out, but it can often narrow down the problem code to a fairly small set. I'm afraid I can't help with such things at the moment, cause I'm not setup to build with MingW on windows. On Tue, Aug 5, 2008 at 7:09 PM, Lenard Lindstrom [EMAIL PROTECTED]mailto: [EMAIL PROTECTED] wrote: The rebuilt SDL.dll still fails. The problem is MinGW related. And SDL does have code for blitting a surface to itself. Lenard Lenard Lindstrom wrote: I wonder if it is the hermes blit library or some piece of inlined MMX code. These would not be included in a VC build. I will build SDL with assembly code turned off and see what happens.
Re: [pygame] Another blitting surface to itself crash
As this is a case where the symptom is not connected to the cause (so looking at the crash in a debugger may not help much) but it seems the problem can be reproduced consistently no problem, Maybe this is a good circumstance for binary search debugging? getting and building SDL from different SVN revisions may be a great way to do that. For me, the prebuilt 1.2.9 doesn't crash but the prebuilt 1.2.10 does (although not on the very first blit to self). If MingW built SDL's behave that same way, then one could do a binary search of SDL's built from the revision numbers between the 2 releases to target things down to a specific code change that made it happen. likewise the repro behavior of the bug changed from 1.2.11 to 1.2.12, so a binary search between those revisions may be good to do as well. Another approach other than using SVN revisions is commenting out functionality (so making it so only half of the code needed to do blit to self executes, and seeing if the crash still happpens). Of course that makes blit-to-surface not have the right behavior, and you need to be a careful about how you comment out, but it can often narrow down the problem code to a fairly small set. I'm afraid I can't help with such things at the moment, cause I'm not setup to build with MingW on windows. On Tue, Aug 5, 2008 at 7:09 PM, Lenard Lindstrom [EMAIL PROTECTED] wrote: The rebuilt SDL.dll still fails. The problem is MinGW related. And SDL does have code for blitting a surface to itself. Lenard Lenard Lindstrom wrote: I wonder if it is the hermes blit library or some piece of inlined MMX code. These would not be included in a VC build. I will build SDL with assembly code turned off and see what happens.
Re: [pygame] Another blitting surface to itself crash
hi, Does it work if you put this at the top of your file? import os os.environ['SDL_VIDEODRIVER'] ='directx' cheers, On Tue, Aug 5, 2008 at 5:37 PM, David Muffley [EMAIL PROTECTED] wrote: With the default SDL.dll from 1.8.1 on Windows 2000sp4 with Python 2.5 import pygame a = pygame.Surface((10,10)) a.blit(a, (0, 0)) # CRASHES ## a.blit(a, (1, 0)) # CRASHES ## a.blit(a, (0, 0), (0,0,9,9)) # CRASHES ## a.blit(a, (0, 0), (1,1,9,9)) # SUCCEEDS ## On Mon, Aug 4, 2008 at 10:39 PM, Brian Fisher [EMAIL PROTECTED] wrote: OK, so basically I've got an SDL I built myself that I'd like other people who are experiencing this problem to try out. SDL is zipped up here: thorbrian.com/SDL_TestBlitToSelf.zip Using this version on the same machine, all the above self-blits worked.
Re: [pygame] Another blitting surface to itself crash
For what it's worth, when I was testing various SDL builds on my machine, the SDL_VIDEODRIVER setting never made any difference at all as to whether the blit-to-self's crashed. On Tue, Aug 5, 2008 at 12:47 AM, René Dudfield [EMAIL PROTECTED] wrote: hi, Does it work if you put this at the top of your file? import os os.environ['SDL_VIDEODRIVER'] ='directx' cheers, On Tue, Aug 5, 2008 at 5:37 PM, David Muffley [EMAIL PROTECTED] wrote: With the default SDL.dll from 1.8.1 on Windows 2000sp4 with Python 2.5 import pygame a = pygame.Surface((10,10)) a.blit(a, (0, 0)) # CRASHES ## a.blit(a, (1, 0)) # CRASHES ## a.blit(a, (0, 0), (0,0,9,9)) # CRASHES ## a.blit(a, (0, 0), (1,1,9,9)) # SUCCEEDS ## On Mon, Aug 4, 2008 at 10:39 PM, Brian Fisher [EMAIL PROTECTED] wrote: OK, so basically I've got an SDL I built myself that I'd like other people who are experiencing this problem to try out. SDL is zipped up here: thorbrian.com/SDL_TestBlitToSelf.zip Using this version on the same machine, all the above self-blits worked.
Re: [pygame] Another blitting surface to itself crash
Actually, the SDL_VIDEODRIVER var is set to directx already, with either SDL.dll. Is that normal? I didn't change anything by myself prior to this. On Tue, Aug 5, 2008 at 3:47 AM, René Dudfield [EMAIL PROTECTED] wrote: hi, Does it work if you put this at the top of your file? import os os.environ['SDL_VIDEODRIVER'] ='directx' cheers, On Tue, Aug 5, 2008 at 5:37 PM, David Muffley [EMAIL PROTECTED] wrote: With the default SDL.dll from 1.8.1 on Windows 2000sp4 with Python 2.5 import pygame a = pygame.Surface((10,10)) a.blit(a, (0, 0)) # CRASHES ## a.blit(a, (1, 0)) # CRASHES ## a.blit(a, (0, 0), (0,0,9,9)) # CRASHES ## a.blit(a, (0, 0), (1,1,9,9)) # SUCCEEDS ## On Mon, Aug 4, 2008 at 10:39 PM, Brian Fisher [EMAIL PROTECTED] wrote: OK, so basically I've got an SDL I built myself that I'd like other people who are experiencing this problem to try out. SDL is zipped up here: thorbrian.com/SDL_TestBlitToSelf.zip Using this version on the same machine, all the above self-blits worked.
Re: [pygame] Another blitting surface to itself crash
I think somebody must have made that change for XP and earlier OS' in pygame. you should be able to test the alternative (windib) with: os.environ['SDL_VIDEODRIVER'] ='windib' On Tue, Aug 5, 2008 at 10:32 AM, David Muffley [EMAIL PROTECTED]wrote: Actually, the SDL_VIDEODRIVER var is set to directx already, with either SDL.dll. Is that normal? I didn't change anything by myself prior to this. On Tue, Aug 5, 2008 at 3:47 AM, René Dudfield [EMAIL PROTECTED] wrote: hi, Does it work if you put this at the top of your file? import os os.environ['SDL_VIDEODRIVER'] ='directx' cheers, On Tue, Aug 5, 2008 at 5:37 PM, David Muffley [EMAIL PROTECTED] wrote: With the default SDL.dll from 1.8.1 on Windows 2000sp4 with Python 2.5 import pygame a = pygame.Surface((10,10)) a.blit(a, (0, 0)) # CRASHES ## a.blit(a, (1, 0)) # CRASHES ## a.blit(a, (0, 0), (0,0,9,9)) # CRASHES ## a.blit(a, (0, 0), (1,1,9,9)) # SUCCEEDS ## On Mon, Aug 4, 2008 at 10:39 PM, Brian Fisher [EMAIL PROTECTED] wrote: OK, so basically I've got an SDL I built myself that I'd like other people who are experiencing this problem to try out. SDL is zipped up here: thorbrian.com/SDL_TestBlitToSelf.zip Using this version on the same machine, all the above self-blits worked.
Re: [pygame] Another blitting surface to itself crash
The aggressive test_blit_to_self.py runs without problems for the replacement SDL.dll. Remember I was getting a corrupted Python string rather than a Pygame parachute. I wonder if it is the hermes blit library or some piece of inlined MMX code. These would not be included in a VC build. I will build SDL with assembly code turned off and see what happens. Lenard Brian Fisher wrote: OK, so basically I've got an SDL I built myself that I'd like other people who are experiencing this problem to try out. SDL is zipped up here: thorbrian.com/SDL_TestBlitToSelf.zip http://thorbrian.com/SDL_TestBlitToSelf.zip basically the idea is to replace the SDL.dll in your pygame subfolder of site-packages with this, and to see if you still get a crash/parachute when blitting a surface to itself. Again, this is on Windows specifically.
Re: [pygame] Another blitting surface to itself crash
The rebuilt SDL.dll still fails. The problem is MinGW related. And SDL does have code for blitting a surface to itself. Lenard Lenard Lindstrom wrote: I wonder if it is the hermes blit library or some piece of inlined MMX code. These would not be included in a VC build. I will build SDL with assembly code turned off and see what happens.
Re: [pygame] Another blitting surface to itself crash
could you try compiling that file with less optimisation(just -O maybe), and see if that helps? On Wed, Aug 6, 2008 at 12:09 PM, Lenard Lindstrom [EMAIL PROTECTED] wrote: The rebuilt SDL.dll still fails. The problem is MinGW related. And SDL does have code for blitting a surface to itself. Lenard Lenard Lindstrom wrote: I wonder if it is the hermes blit library or some piece of inlined MMX code. These would not be included in a VC build. I will build SDL with assembly code turned off and see what happens.
Re: [pygame] Another blitting surface to itself crash
Hi this has worked on my machine: http://www.pygame.org/pcr/meltdown/index.php (but now using 1.8 from the pygame.org site it crashes) IIRC I was told, that when blitting a surface on itself the sourerect is important (I dont remember how it should be, sorry). Maybe this is the problem? I dont have time to test. ~DR0ID Hugo Arts schrieb: On Sat, Aug 2, 2008 at 6:30 PM, Brian Fisher [EMAIL PROTECTED] wrote: There's another instance of blitting a surface to itself crashing on Windows for a user, it's believed to be a 1.8.1 thing by the poster http://pygame.motherhamster.org/bugzilla/show_bug.cgi?id=19 last time it came up marcus was thinking about making pygame throw an exception on blitting a surface to itself, which still seems like a decent solution to me. Anybody know any more background? I was the one who submitted the bug last time. At the time there was some resistance to the exception solution, since scrolling was seen as a valid reason to blit surfaces onto themselves, as well as a certain meltdown effect. There is an easy workaround available (just copy the surface), but no fix. As far as I could tell, the bug occurs only on windows. We never got into the cause of the bug, the thread died down without any real bug hunting done. I have no idea what could be causing this. At the time I wrote this minimal script to reproduce, works also in interactive mode: import pygame pygame.init() a = pygame.Surface((10, 10)) a.blit(a, (0, 0)) Output: Fatal Python error: (pygame parachute) Segmentation Fault That's about all I know. Hugo
Re: [pygame] Another blitting surface to itself crash
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. Lenard Brian Fisher wrote: Thanks Hugo. So the crash when blitting a surface to itself is in SDL, and it doesn't seem to happen with SDL 1.2.5 or SDL 1.2.7 (you can actually run pygame 1.8.1 over those versions, you just have to ignore the function not found message boxes). no SDL bug for this exists, at the moment. I haven't tried debugging what's happening in SDL yet, because I'm not currently set up to build SDL., so if anyone equipped to do some SDL debugging of this (I believe it's a windows only problem) would be interested, I would appreciate them investigating this --- I would try looking at a crash minidmp (do the cygwin dependency builds have pdb files or some other debug symbols?), except this is one of those pygame parachute things that don't seem to actually crash and have the os make a minidump... does anybody know if there is a way to disable the pygame parachute thing and get an actual crash? On Sat, Aug 2, 2008 at 3:32 PM, Hugo Arts [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sat, Aug 2, 2008 at 6:30 PM, Brian Fisher [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: There's another instance of blitting a surface to itself crashing on Windows for a user, it's believed to be a 1.8.1 thing by the poster http://pygame.motherhamster.org/bugzilla/show_bug.cgi?id=19 last time it came up marcus was thinking about making pygame throw an exception on blitting a surface to itself, which still seems like a decent solution to me. Anybody know any more background? I was the one who submitted the bug last time. At the time there was some resistance to the exception solution, since scrolling was seen as a valid reason to blit surfaces onto themselves, as well as a certain meltdown effect. There is an easy workaround available (just copy the surface), but no fix. As far as I could tell, the bug occurs only on windows. We never got into the cause of the bug, the thread died down without any real bug hunting done. I have no idea what could be causing this. At the time I wrote this minimal script to reproduce, works also in interactive mode: import pygame pygame.init() a = pygame.Surface((10, 10)) a.blit(a, (0, 0)) Output: Fatal Python error: (pygame parachute) Segmentation Fault That's about all I know. Hugo -- Lenard Lindstrom [EMAIL PROTECTED]
Re: [pygame] Another blitting surface to itself crash
On 8/2/08, Brian Fisher [EMAIL PROTECTED] wrote: last time it came up marcus was thinking about making pygame throw an exception on blitting a surface to itself, which still seems like a decent solution to me. Anybody know any more background? The root of such problems is why people need to blit on the same surface? Usually it is because they just need to scroll it a bit to avoid repainting the whole thing from scratch. Perhaps some scroll methods will be more welcomed than another exception to process. -- --anatoly t.
Re: [pygame] Another blitting surface to itself crash
On 8/2/08, Brian Fisher [EMAIL PROTECTED] wrote: There's another instance of blitting a surface to itself crashing on Windows for a user, it's believed to be a 1.8.1 thing by the poster http://pygame.motherhamster.org/bugzilla/show_bug.cgi?id=19 last time it came up marcus was thinking about making pygame throw an exception on blitting a surface to itself, which still seems like a decent solution to me. Anybody know any more background? time ago I reported this, see http://article.gmane.org/gmane.comp.python.pygame/12087 At the time it was a pygame 1.7.1 bug, looking windows specific ( developers on Linux got no problem with blit over itself ), and the SDL version was wathever linked - recomended at pygame site ( the binaries readme tells it is 1.2.7 )
Re: [pygame] Another blitting surface to itself crash
I think you are right anatoly, in that doing something special for scrolling is what is the right thing, and having an api that blocks blitting to itself but has a special call for scroll would be the ideal api. However I remember way back when SDL was much younger (like late 1990's) blits of a surface to itself would not crash (why should they?) but would instead do what you would expect for an efficient blit routine - if you blitted with an offset opposite the sequential order that the blit would be performed in, you'd end up tiling or repeating some portion of the image all over itself (because as you'd copy pixels into parts of the source you havent copied from yet, you'd be overwriting the source image before you got to use it) So the fact that anybody is able to use this blitting a surface to itself trick to scroll in 4 directions without getting crap results, means that SDL must have implemented some sort of blit a surface to itself magic that involves either changing the sequential blit direction, or using intermediate copies of some sort. Which basically means SDL must have special code that says blit to self = do blit that is safe for scrolling operation So given that, it seems to me that bliting a surface to itself should be a valid op in SDL land starting at some point post-2000, but for that the code somehow got broken on windows in some revision. On Sun, Aug 3, 2008 at 10:45 AM, techtonik [EMAIL PROTECTED] wrote: The root of such problems is why people need to blit on the same surface? Usually it is because they just need to scroll it a bit to avoid repainting the whole thing from scratch. Perhaps some scroll methods will be more welcomed than another exception to process. -- --anatoly t.
Re: [pygame] Another blitting surface to itself crash
Just comment out line 606 in core.c: install_parachute (); That should do it. If I have time I can build SDL with debug info. and check it out once I have an idea where to look. Happy bug hunting, Lenard Brian Fisher wrote: 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 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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.
Re: [pygame] Another blitting surface to itself crash
That should be base.c. Why I keep thinking of core I don't know. Lenard Lenard Lindstrom wrote: Just comment out line 606 in core.c: install_parachute (); That should do it. If I have time I can build SDL with debug info. and check it out once I have an idea where to look. Happy bug hunting, Lenard Brian Fisher wrote: 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 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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.
Re: [pygame] Another blitting surface to itself crash
On Sat, Aug 2, 2008 at 6:30 PM, Brian Fisher [EMAIL PROTECTED] wrote: There's another instance of blitting a surface to itself crashing on Windows for a user, it's believed to be a 1.8.1 thing by the poster http://pygame.motherhamster.org/bugzilla/show_bug.cgi?id=19 last time it came up marcus was thinking about making pygame throw an exception on blitting a surface to itself, which still seems like a decent solution to me. Anybody know any more background? I was the one who submitted the bug last time. At the time there was some resistance to the exception solution, since scrolling was seen as a valid reason to blit surfaces onto themselves, as well as a certain meltdown effect. There is an easy workaround available (just copy the surface), but no fix. As far as I could tell, the bug occurs only on windows. We never got into the cause of the bug, the thread died down without any real bug hunting done. I have no idea what could be causing this. At the time I wrote this minimal script to reproduce, works also in interactive mode: import pygame pygame.init() a = pygame.Surface((10, 10)) a.blit(a, (0, 0)) Output: Fatal Python error: (pygame parachute) Segmentation Fault That's about all I know. Hugo
Re: [pygame] Another blitting surface to itself crash
Thanks Hugo. So the crash when blitting a surface to itself is in SDL, and it doesn't seem to happen with SDL 1.2.5 or SDL 1.2.7 (you can actually run pygame 1.8.1 over those versions, you just have to ignore the function not found message boxes). no SDL bug for this exists, at the moment. I haven't tried debugging what's happening in SDL yet, because I'm not currently set up to build SDL., so if anyone equipped to do some SDL debugging of this (I believe it's a windows only problem) would be interested, I would appreciate them investigating this --- I would try looking at a crash minidmp (do the cygwin dependency builds have pdb files or some other debug symbols?), except this is one of those pygame parachute things that don't seem to actually crash and have the os make a minidump... does anybody know if there is a way to disable the pygame parachute thing and get an actual crash? On Sat, Aug 2, 2008 at 3:32 PM, Hugo Arts [EMAIL PROTECTED] wrote: On Sat, Aug 2, 2008 at 6:30 PM, Brian Fisher [EMAIL PROTECTED] wrote: There's another instance of blitting a surface to itself crashing on Windows for a user, it's believed to be a 1.8.1 thing by the poster http://pygame.motherhamster.org/bugzilla/show_bug.cgi?id=19 last time it came up marcus was thinking about making pygame throw an exception on blitting a surface to itself, which still seems like a decent solution to me. Anybody know any more background? I was the one who submitted the bug last time. At the time there was some resistance to the exception solution, since scrolling was seen as a valid reason to blit surfaces onto themselves, as well as a certain meltdown effect. There is an easy workaround available (just copy the surface), but no fix. As far as I could tell, the bug occurs only on windows. We never got into the cause of the bug, the thread died down without any real bug hunting done. I have no idea what could be causing this. At the time I wrote this minimal script to reproduce, works also in interactive mode: import pygame pygame.init() a = pygame.Surface((10, 10)) a.blit(a, (0, 0)) Output: Fatal Python error: (pygame parachute) Segmentation Fault That's about all I know. Hugo
