我从源代码构建的 SDL 库崩溃了!
我已经使用 bcc 5.5.1 从源代码成功构建了 SDL,但使用它的任何 SDL 测试应用程序在启动时都会立即崩溃。我正在寻找有关如何解决此问题的一些帮助和/或指导。
只是为了填写一些信息,使用了 SDL-1.2.14。该项目被编译为启用多线程的 dll,并动态链接到 C 运行时。我还使用调试信息重建了它。当我使用调试器逐步执行到崩溃点时,它似乎来自 sdlmain 中的redirect_stdout。如果我删除 sdlmain.lib 并直接在 SDL 测试项目中使用源文件 sdl_win32_main.c ,那么就不会再崩溃了。相反,它只是稍后在 SDL_Init 例程中崩溃。
我已经检查了所使用的调用约定,它们似乎都匹配——一切都使用 cdecl。我还检查并确保编译的 sdl.dll 和测试应用程序使用相同的动态 C 运行时而不是静态链接。
Borland 部分下的 SDL wiki 提到使用 -b 来确保 enum 的大小与 int 相同,但编译器默认启用该选项,除非明确关闭。为了确定起见,我确实使用编译器/链接器开关重建了 SDL。
当它崩溃时,尝试写入某个地址(c000005)时总是发生访问冲突。例如,在典型的 SDL 初始化尝试期间,如下所示:
// initialize SDL video
if ( SDL_Init( SDL_INIT_VIDEO ) < 0 )
{
printf( "Unable to init SDL: %s\n", SDL_GetError() );
return 1;
}
调用 SDL_Init() 后,控制不会流回测试应用程序。相反,它会在某个奇怪的地方崩溃,比如 ntdll.dll 中与 NTDLL.RtlEnterCriticalSection 有关的某个地方。当我检查此时的堆栈跟踪时,我通常会得到这样的信息:
: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'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
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
好吧,前几天我终于知道问题出在哪里了。崩溃的原因是为给定平台编译了错误的源文件。
我使用的项目文件不断从threads\generic编译SDL_sysmutex.c。在 win32 下使用的正确 SDL_sysmutex.c 应该来自threads\win32。当我并排跟踪测试程序并且线程模块具有不同的代码行时,我发现了这一点!
通过修复这个小疏忽,崩溃问题几乎消失了,所有测试演示都按预期运行:)
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 :)