[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Another blitting surface to itself crash



Douglas Bagnall wrote:
Lenard Lindstrom 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.

This sounds related to the ABI "correction" in GCC 4.3 that broke a
lot more than SDL:

http://lwn.net/Articles/272048/

If it is, the SDL code would have worked with older compilers.

Pygame 1.8 for Windows is compiled with gcc 3.4.5. This is to avoid surprises while stomping 1.8 bugs. I have tried gcc-sjlj 4.2.1 (set-jump, long-jump exception handling) and it works, though a patch to distutils is need (just applied to Python in SVN). An alpha version of 4.3 was released for MinGW in May. So it will be awhile before it is used with Pygame.

As to where the DF is causing problems is still a mystery. Other SDL assembly code explicitly clear the direction flag before any string operations. A quick test program showed no problems with Microsoft's strcpy and memcpy.

--
Lenard Lindstrom
<len-l@xxxxxxxxx>