We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3086

Summary: GP fault on initialization local variables in SDL_RenderCopy
Product: SDL Reporter: Evgeniy <de-sign-it>
Component: renderAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED ABANDONED QA Contact: Sam Lantinga <slouken>
Severity: minor    
Priority: P5    
Version: 2.0.3   
Hardware: x86   
OS: Linux   
Attachments: screenshot

Description Evgeniy 2015-08-07 07:31:40 UTC
Created attachment 2236 [details]
screenshot

I build simple project that uses SDL2 (source below), but it suddenly raises GP exception. Good idea to build SDL2 with debug information. It helped me find place in source that causes an exception. gcc compiles initialization of local variable into movAps assembler instruction, but did not care about alignment. If gcc does not follow the alignment it must use movUps instruction. Perhaps I need to add some build options to compiler, when I build SDL2?

OS: Linux Mint 17.2
uname -a: Linux computer 3.16.0-38-generic #52~14.04.1-Ubuntu SMP Fri May 8 09:44:48 UTC 2015 i686 athlon i686 GNU/Linux
My IDE: Lazarus 1.4.0
My compiler: Free Pascal 2.6.4
SDL2 was build with: >./configure && make && sudo install
Screenshot attached (Lazarus shows assembler instructions in AT&T style)

Source:
var
  sdl_surface : PSDL_Surface;
  sdl_rect    : TSDL_Rect;
  sdlWindow1  : PSDL_Window;
  sdlRenderer : PSDL_Renderer;
  sdlTexture1 : PSDL_Texture;
begin
  if SDL_Init( SDL_INIT_VIDEO ) < 0 then HALT;

  sdlWindow1 := SDL_CreateWindow( 'Window1', 50, 50, 500, 500, SDL_WINDOW_SHOWN );
  if sdlWindow1 = nil then HALT;

  sdlRenderer := SDL_CreateRenderer( sdlWindow1, -1, 0 );
  if sdlRenderer = nil then HALT;

  sdl_Surface := SDL_LoadBMP_RW(SDL_RWFromFile('sdl_image.bmp', 'rb'), 1);
  sdlTexture1 := SDL_CreateTextureFromSurface( sdlRenderer, sdl_surface );
  SDL_FreeSurface(sdl_surface);
  if sdlTexture1 = nil then HALT;
  sdl_rect.x:=0;
  sdl_rect.y:=0;
  sdl_rect.w:=100;
  sdl_rect.h:=100;
  SDL_RenderCopy( sdlRenderer, sdlTexture1, @sdl_rect, @sdl_rect );
  SDL_RenderPresent (sdlRenderer);
  SDL_Delay( 10000 );

  SDL_DestroyTexture( sdlTexture1 );
  SDL_DestroyRenderer( sdlRenderer );
  SDL_DestroyWindow ( sdlWindow1 );
  SDL_Quit;
end;
Comment 1 Evgeniy 2015-08-07 08:41:29 UTC
Problem solved by:
...
{$ASMMODE intel}
  asm
    mov sesp, esp
    and esp, $fffffff0
  end;
  SDL_RenderCopy( sdlRenderer, sdlTexture1, nil, nil );
  asm
    mov esp, sesp
  end;
...

It turns out that is not so much an bug as a question of coordination between caller and routine. SDL2 aligned on 16 byte to be compatible with SSE instructions, but fpc is not. So may be add code like above in SDL_DYNAPI_PROC macro (for example) for support compilers like fpc?
Comment 2 Sam Lantinga 2017-08-12 23:29:18 UTC
Ryan, is this something we need to do in SDL? Or should we be decorating the function declarations in some way?
Comment 3 Ryan C. Gordon 2018-08-06 21:20:19 UTC
Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.