Home/ Questions/Q 1013899
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T10:10:26+00:00

I’ve successfully built SDL from source using bcc 5.5.1 but any SDL test application

  • 0

I’ve successfully built SDL from source using bcc 5.5.1 but any SDL test application using it crashes right away at startup. I’m looking for some help and/or guidance on how to resolve this issue.

Just to fill in some info, SDL-1.2.14 was used. The project’s compiled as a dll with multithreading enabled and linked to C runtime dynamically. I’ve also rebuilt it with debugging info. When I step through with a debugger up to the point of crash it seems to be coming from redirect_stdout in the sdlmain. If I remove sdlmain.lib and use the source file sdl_win32_main.c directly in the SDL test project then that doesn’t crash anymore. Instead it just crashes later on at SDL_Init routine.

I’ve already checked the calling conventions used and they all seem to match up — everything is using cdecl. I’ve also checked and made sure the compiled sdl.dll and the test application was using the same dynamic c runtime instead of statically linked.

The SDL wiki under Borland section mentions to use the -b to make sure enum’s are same size as int but that option is enabled by the compiler by default unless explicitly turned off. I did rebuild SDL with that compiler/linker switch just to be sure though.

When it crashes, it’s always a access violation in trying to write to some address(c000005). Like for example during a typical SDL init attempt like this:

// initialize SDL video
if ( SDL_Init( SDL_INIT_VIDEO ) < 0 )
{
    printf( "Unable to init SDL: %s\n", SDL_GetError() );
    return 1;
}

After the call into SDL_Init(), control doesn’t flow back into the test application. Instead it crashes somewhere bizarre like somewhere in ntdll.dll with something having to do with NTDLL.RtlEnterCriticalSection. When I inspect the stack trace at that point I usually get something like this:

:77982269
:0044A04C
:0043F02B
:0043F7C4
:0043EF25
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
//and it keeps recursing... looks like a stackover? :P

I’m not sure whatelse to try at this point as I’m pretty stumped. If anyone have any suggestions or need me to provide more info please feel free to add it to the comments.

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Alright, I finally found out what the issue was a couple days ago. The reason for the crash was because the wrong source file was compiled for the given platform.

    The project file I used kept compiling SDL_sysmutex.c from threads\generic. The correct SDL_sysmutex.c to use under win32 should have been from threads\win32. I found this out when I was tracing the test programs side by side and the threading modules had different lines of code!

    With this little oversight fixed the crashing problems have all but disappeared and all the test demos are running as they should 🙂

    • 0