It took a bit of work to track this one down, but here goes:
When I try to perform a certain render under the software renderer, I get an access violation deep within the bowels of the blitting code. Here’s the top of the call stack, from Visual C++:
SDL.dll!Blit1to4(SDL_BlitInfo * info=0x05c7a570) Line 262 + 0x32 bytes C
SDL.dll!SDL_SoftBlit(SDL_Surface * src=0x05c7a4c8, SDL_Rect * srcrect=0x0018ecc8, SDL_Surface * dst=0x026a04a8, SDL_Rect * dstrect=0x0018ecb8) Line 89 + 0x7 bytes C
SDL.dll!SDL_LowerBlit(SDL_Surface * src=0x05c7a4c8, SDL_Rect * srcrect=0x0018ecc8, SDL_Surface * dst=0x026a04a8, SDL_Rect * dstrect=0x0018ecb8) Line 638 + 0x1b bytes C
SDL.dll!SW_RenderCopy(SDL_Renderer * renderer=0x026a1b58, SDL_Texture * texture=0x05c7a490, const SDL_Rect * srcrect=0x0018ed6c, const SDL_Rect * dstrect=0x0018ed5c) Line 829 + 0x18 bytes C
SDL.dll!SDL_RenderCopy(SDL_Texture * texture=0x05c7a490, const SDL_Rect * srcrect=0x0018eddc, const SDL_Rect * dstrect=0x00000000) Line 2591 + 0x18 bytes C
Turbu.exe!004b12d1()
It occurs within the DUFFS_LOOP macro in the following loop:
while (height--) {
#ifdef USE_DUFFS_LOOP
/* INDENT-OFF */
DUFFS_LOOP(
*dst++ = map[src++];
, width);
/ INDENT-ON /
#else
//snipped
#endif / USE_DUFFS_LOOP */
src += srcskip;
dst += dstskip;
}
First-chance exception at 0x5e3a0276 (SDL.dll) in Turbu.exe: Access violation reading location 0x09e80000.
when height = 112.
According to the debugger, at this point src=0x09e80000, which is an invalid memory location.
The strange thing is, in the old build, I was apparently using the software renderer without knowing it, and I never had this problem. Has anything changed in the SW renderer’s blitting in the last 5 months or so?
Can you verify the parameters on entering the function?
Can you reproduce it in the tests or create a test case?On Wed, Apr 14, 2010 at 3:09 PM, Mason Wheeler wrote:
It took a bit of work to track this one down, but here goes:
When I try to perform a certain render under the software renderer, I get an access violation deep within the bowels of the blitting code. ?Here’s the top of the call stack, from Visual C++:
? ?SDL.dll!Blit1to4(SDL_BlitInfo * info=0x05c7a570) ?Line 262 + 0x32 bytes ? ?C
? ? SDL.dll!SDL_SoftBlit(SDL_Surface * src=0x05c7a4c8, SDL_Rect * srcrect=0x0018ecc8, SDL_Surface * dst=0x026a04a8, SDL_Rect * dstrect=0x0018ecb8) ?Line 89 + 0x7 bytes ? ?C
? ? SDL.dll!SDL_LowerBlit(SDL_Surface * src=0x05c7a4c8, SDL_Rect * srcrect=0x0018ecc8, SDL_Surface * dst=0x026a04a8, SDL_Rect * dstrect=0x0018ecb8) ?Line 638 + 0x1b bytes ? ?C
? ? SDL.dll!SW_RenderCopy(SDL_Renderer * renderer=0x026a1b58, SDL_Texture * texture=0x05c7a490, const SDL_Rect * srcrect=0x0018ed6c, const SDL_Rect * dstrect=0x0018ed5c) ?Line 829 + 0x18 bytes ? ?C
? ? SDL.dll!SDL_RenderCopy(SDL_Texture * texture=0x05c7a490, const SDL_Rect * srcrect=0x0018eddc, const SDL_Rect * dstrect=0x00000000) ?Line 2591 + 0x18 bytes ? ?C
? ? Turbu.exe!004b12d1()
It occurs within the DUFFS_LOOP macro in the following loop:
? ?while (height–) {
#ifdef USE_DUFFS_LOOP
? ? ? ?/* INDENT-OFF */
? ? ? ?DUFFS_LOOP(
? ? ? ? ? ?*dst++ = map[src++];
? ? ? ?, width);
? ? ? ?/ INDENT-ON /
#else
? //snipped
#endif / USE_DUFFS_LOOP */
? ? ? ?src += srcskip;
? ? ? ?dst += dstskip;
? ?}
First-chance exception at 0x5e3a0276 (SDL.dll) in Turbu.exe: Access violation reading location 0x09e80000.
when height = 112.
According to the debugger, at this point src=0x09e80000, which is an invalid memory location.
The strange thing is, in the old build, I was apparently using the software renderer without knowing it, and I never had this problem. ?Has anything changed in the SW renderer’s blitting in the last 5 months or so?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
All right. I’ve put together a very simple test case at
http://www.turbu-rpg.com/downloads/sdl_software_testcase.zip
It’s in Delphi, using my SDL Frame component, but there’s a
prebuilt EXE in the archive. It requires the 1.3 versions of
SDL.dll and SDL_Image.dll. It creates a simple HWND region
with a HDC drawing context on the form and passes it to
SDL_CreateWindowFrom, then creates a software renderer
on that window.
The button labeled “Break stuff” will pull up a Load File dialog.
I included a sample image that it will break on, though from
my testing, any 8-bit PNG causes the problem. 32-bit PNGs
will run without breaking the renderer, but nothing displays.
The access violation occurs within the call to SDL_RenderCopy.
Place a breakpoint there for the start of the call chain, or
on Blit1to4 in SDL_blit_1.c for the end of the call chain where
things blow up. Make sure you’ve got Visual Studio configured
to break on an Access Violation exception.
In case it makes a difference, I’m running Windows 7, 64-bit
version, with an ATI Mobility Radeon HD 3780 X2 video
adapter.
Let me know if you need any more information to reproduce
this at your end.>----- Original Message ----
From: Sam Lantinga
Subject: Re: [SDL] Access violation in SDL_RenderCopy under software renderer
Can you verify the parameters on entering the function?
Can you reproduce it in the tests or create a test case?