ntdll.dll!RtlReportCriticalFailure () Unknown ntdll.dll!RtlpHeapHandleError () Unknown ntdll.dll!RtlpHpHeapHandleError () Unknown ntdll.dll!RtlpLogHeapFailure () Unknown ntdll.dll!RtlpAllocateHeap () Unknown ntdll.dll!RtlpAllocateHeapInternal () Unknown > gzdoom.exe!_malloc_base(unsigned __int64 size) Line 34 C++ gzdoom.exe!M_Malloc(unsigned __int64 size) Line 60 C++ [Inline Frame] gzdoom.exe!TArray<JitLineInfo,JitLineInfo>::DoCopy(const TArray<JitLineInfo,JitLineInfo> &) Line 548 C++ [Inline Frame] gzdoom.exe!TArray<JitLineInfo,JitLineInfo>::{ctor}(const TArray<JitLineInfo,JitLineInfo> &) Line 190 C++ gzdoom.exe!AddJitFunction(asmjit::CodeHolder * code, JitCompiler * compiler) Line 308 C++ gzdoom.exe!JitCompile(VMScriptFunction * sfunc) Line 30 C++ gzdoom.exe!VMScriptFunction::FirstScriptCall(VMFunction * func, VMValue * params, int numparams, VMReturn * ret, int numret) Line 297 C++ [External Code] gzdoom.exe!VMCall(VMFunction * func, VMValue * params, int numparams, VMReturn * results, int numresults) Line 580 C++ gzdoom.exe!S_PrecacheLevel(FLevelLocals * Level) Line 358 C++ gzdoom.exe!P_SetupLevel(FLevelLocals * Level, int position, bool newGame) Line 555 C++ gzdoom.exe!FLevelLocals::DoLoadLevel(const FString & nextmapname, int position, bool autosave, bool newGame) Line 1191 C++ [Inline Frame] gzdoom.exe!G_DoLoadLevel(const FString &) Line 1077 C++ gzdoom.exe!G_InitNew(const char * mapname, bool bTitleLevel) Line 555 C++ gzdoom.exe!D_DoAdvanceDemo() Line 1528 C++ gzdoom.exe!TryRunTics() Line 1984 C++ gzdoom.exe!D_DoomLoop() Line 1293 C++ gzdoom.exe!D_DoomMain_Internal() Line 3658 C++ gzdoom.exe!GameMain() Line 3683 C++ gzdoom.exe!DoMain(HINSTANCE__ * hInstance) Line 971 C++ gzdoom.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * nothing, wchar_t * cmdline, int nCmdShow) Line 1260 C++ [External Code]
_mental_ wrote:It’s mostly useless. Strange that it crashes in sndfile though. Please load symbols for system libraries like ntdll. It's in context menu of callstack window.
EDIT: To enable debug information in Release build, add /Zi to CMAKE_C_FLAGS_RELEASE and CMAKE_CXX_FLAGS_RELEASE CMake variables, and /DEBUG to CMAKE_EXE_LINKER_FLAGS_RELEASE variable. The same can be done for ZMusic. The third variable should be CMAKE_SHARED_LINKER_FLAGS.
Or use RelWithDebInfo. Its compiler settings are identical to Release, aside from generating debug info.
Oh duh, I can't believe I didn't even notice that... Coulda saved me a few minutes trying to figure out how to do what mental told me. Oh well...
I've given up trying to get a crash in the debug version, it's just not happening. I also downloaded a fresh zip of dev BoA just to make sure there wasn't any corruption issue like Rachael suggested.
I've switched over to RelWithDebInfo going forward. I also realized you can continue in the debugger after a breakpoint and the call stack gets updated, so I'm not sure if I was supposed to paste just the first break point as I did in my previous post, or if I am supposed to let it continue looking for something in particular... On some launches it brings me to different points first, so I'm not sure if there's something more useful I could be posting... For instance this time I got:
ntdll.dll!RtlReportCriticalFailure () Unknown ntdll.dll!RtlpHeapHandleError () Unknown ntdll.dll!RtlpHpHeapHandleError () Unknown ntdll.dll!RtlpLogHeapFailure () Unknown ntdll.dll!RtlpAllocateHeap () Unknown ntdll.dll!RtlpAllocateHeapInternal () Unknown libsndfile-1.dll!00007fffc36775fb() Unknown libsndfile-1.dll!00007fffc368adef() Unknown libsndfile-1.dll!00007fffc368b65f() Unknown libsndfile-1.dll!00007fffc368710b() Unknown libsndfile-1.dll!00007fffc3686141() Unknown libsndfile-1.dll!00007fffc3652508() Unknown libsndfile-1.dll!00007fffc365182e() Unknown libsndfile-1.dll!00007fffc362eae6() Unknown libsndfile-1.dll!00007fffc363028b() Unknown libsndfile-1.dll!00007fffc36324b4() Unknown zmusic.dll!00007fffe9325f53() Unknown zmusic.dll!00007fffe932575c() Unknown zmusic.dll!00007fffe93259ec() Unknown > gzdoom.exe!OpenALSoundRenderer::LoadSound(unsigned char * sfxdata, int length) Line 1065 C++ gzdoom.exe!SoundEngine::LoadSound(sfxinfo_t * sfx) Line 772 C++ gzdoom.exe!SoundEngine::CacheSound(sfxinfo_t * sfx) Line 172 C++ gzdoom.exe!SoundEngine::CacheMarkedSounds() Line 134 C++ gzdoom.exe!S_PrecacheLevel(FLevelLocals * Level) Line 375 C++ gzdoom.exe!P_SetupLevel(FLevelLocals * Level, int position, bool newGame) Line 555 C++ gzdoom.exe!FLevelLocals::DoLoadLevel(const FString & nextmapname, int position, bool autosave, bool newGame) Line 1191 C++ [Inline Frame] gzdoom.exe!G_DoLoadLevel(const FString &) Line 1077 C++ gzdoom.exe!G_InitNew(const char * mapname, bool bTitleLevel) Line 555 C++ gzdoom.exe!D_DoAdvanceDemo() Line 1528 C++ gzdoom.exe!TryRunTics() Line 1984 C++ gzdoom.exe!D_DoomLoop() Line 1293 C++ gzdoom.exe!D_DoomMain_Internal() Line 3658 C++ gzdoom.exe!GameMain() Line 3683 C++ gzdoom.exe!DoMain(HINSTANCE__ * hInstance) Line 971 C++ gzdoom.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * nothing, wchar_t * cmdline, int nCmdShow) Line 1260 C++ [External Code]
On the next run the first point was something more like the first one I posted:
ntdll.dll!RtlReportCriticalFailure () Unknown ntdll.dll!RtlpHeapHandleError () Unknown ntdll.dll!RtlpHpHeapHandleError () Unknown ntdll.dll!RtlpLogHeapFailure () Unknown ntdll.dll!RtlpAllocateHeap () Unknown ntdll.dll!RtlpAllocateHeapInternal () Unknown > gzdoom.exe!_malloc_base(unsigned __int64 size) Line 34 C++ gzdoom.exe!M_Malloc(unsigned __int64 size) Line 60 C++ gzdoom.exe!TMap<AActor *,bool,THashTraits<AActor *>,TValueTraits<bool>>::SetNodeVector(unsigned int size) Line 1075 C++ [Inline Frame] gzdoom.exe!TMap<AActor *,bool,THashTraits<AActor *>,TValueTraits<bool>>::Resize(unsigned int nhsize) Line 1103 C++ [Inline Frame] gzdoom.exe!TMap<AActor *,bool,THashTraits<AActor *>,TValueTraits<bool>>::Rehash() Line 1120 C++ gzdoom.exe!TMap<AActor *,bool,THashTraits<AActor *>,TValueTraits<bool>>::NewKey(AActor * const key) Line 1153 C++ [Inline Frame] gzdoom.exe!TMap<FTexture *,bool,THashTraits<FTexture *>,TValueTraits<bool>>::Insert(FTexture * const) Line 985 C++ gzdoom.exe!hw_PrecacheTexture(unsigned char * texhitlist, TMap<PClassActor *,bool,THashTraits<PClassActor *>,TValueTraits<bool>> & actorhitlist) Line 115 C++ gzdoom.exe!PrecacheLevel(FLevelLocals * Level) Line 227 C++ gzdoom.exe!P_SetupLevel(FLevelLocals * Level, int position, bool newGame) Line 552 C++ gzdoom.exe!FLevelLocals::DoLoadLevel(const FString & nextmapname, int position, bool autosave, bool newGame) Line 1191 C++ [Inline Frame] gzdoom.exe!G_DoLoadLevel(const FString &) Line 1077 C++ gzdoom.exe!G_InitNew(const char * mapname, bool bTitleLevel) Line 555 C++ gzdoom.exe!D_DoAdvanceDemo() Line 1528 C++ gzdoom.exe!TryRunTics() Line 1984 C++ gzdoom.exe!D_DoomLoop() Line 1293 C++ gzdoom.exe!D_DoomMain_Internal() Line 3658 C++ gzdoom.exe!GameMain() Line 3683 C++ gzdoom.exe!DoMain(HINSTANCE__ * hInstance) Line 971 C++ gzdoom.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * nothing, wchar_t * cmdline, int nCmdShow) Line 1260 C++ [External Code]
I'm guessing this all might not be very useful if no one else is going to be able to reproduce it, but I do encourage anyone that is interested to try it in RelWithDebInfo instead of Debug, if they haven't already.
Files are Wolfendoom-master folder from git, dummy ipk3 with iwadinfo, and my dev BoA mapinfo from the first post.
Also I probably shouldn't even speculate, but I was wondering if the reason the debug build isn't crashing for me is precisely because it's slower, and there's some sort of race condition? And this is why sometimes it works even in the release version for me with the config in the most likely to crash state, just by dumb random chance... and loading doa_bt.pk3 or not also impacts how fast something is getting done and influences if the crash conditions are met...
Anyway, like I said, I probably shouldn't speculate, sorry...
Sorry to keep bumping this thread but I just discovered something incredibly weird that may or may not be useful...
If I add "+map titlemap" to the command line, the crash frequency is reduced to the point where I haven't actually seen it happen yet after at least 10 launches. If nothing else, at least I now have a practical workaround for this strange issue...
Debug information is not the only difference between Release and RelWithDebInfo. The former uses /Ob2 (compiler can inline everything except explicit noinlines) while the latter uses /Ob1 (which skips implicit candidates for inlining). If the given crash happens with RelWithDebInfo too, this doesn't mean that code generated by both configurations are identical. And as long as we don't know what causes the crash, I saw no reason to add another variable to the equation.
Regarding the problem itself, I still cannot reproduce it. Breakpoint on RtlpLogHeapFailure() function never triggered for me. What's in the Output window when this happens? Some error information should be there.
In GZDoom this was explicilty changed to use the same flags for Release and RelWithDebInfo, because otherwise RelWithDebInfo would be useless, if it cannot be used to debug actual release builds. No idea what the CMake people were smoking here.
ntdll.dll!RtlReportCriticalFailure () Unknown ntdll.dll!RtlpHeapHandleError () Unknown ntdll.dll!RtlpHpHeapHandleError () Unknown ntdll.dll!RtlpLogHeapFailure () Unknown ntdll.dll!RtlpFreeHeap () Unknown ntdll.dll!RtlpFreeHeapInternal() Unknown ntdll.dll!RtlFreeHeap() Unknown > gzdoom.exe!_free_base(void * block) Line 105 C++ gzdoom.exe!M_Free(void * block) Line 203 C++ [Inline Frame] gzdoom.exe!TArray<unsigned char,unsigned char>::{dtor}() Line 237 C++ gzdoom.exe!PrecacheLevel(FLevelLocals * Level) Line 229 C++ gzdoom.exe!P_SetupLevel(FLevelLocals * Level, int position, bool newGame) Line 552 C++ gzdoom.exe!FLevelLocals::DoLoadLevel(const FString & nextmapname, int position, bool autosave, bool newGame) Line 1191 C++ [Inline Frame] gzdoom.exe!G_DoLoadLevel(const FString &) Line 1077 C++ gzdoom.exe!G_InitNew(const char * mapname, bool bTitleLevel) Line 555 C++ gzdoom.exe!D_DoAdvanceDemo() Line 1528 C++ gzdoom.exe!TryRunTics() Line 1984 C++ gzdoom.exe!D_DoomLoop() Line 1293 C++ gzdoom.exe!D_DoomMain_Internal() Line 3658 C++ gzdoom.exe!GameMain() Line 3683 C++ gzdoom.exe!DoMain(HINSTANCE__ * hInstance) Line 971 C++ gzdoom.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * nothing, wchar_t * cmdline, int nCmdShow) Line 1260 C++ [External Code]
Also I assume when you say output window you mean in VS:
Calls to FTextureManager::CheckForTexture() function here and here may create a new texture. However, the size of the hitlist is set once at the beginning of precaching process. We need to grow the hitlist if we want to create new textures here, or pass TEXMAN_DontCreate if we don't need to do this. I cannot decide which one is right for precaching.
_mental_ wrote:Calls to FTextureManager::CheckForTexture() function here and here may create a new texture. However, the size of the hitlist is set once at the beginning of precaching process. We need to grow the hitlist if we want to create new textures here, or pass TEXMAN_DontCreate if we don't need to do this. I cannot decide which one is right for precaching.
I wish I knew enough to make use of this info and experiment with it, but alas, I am but a simple user. I did however just want to say that I finally took some time to try this on my work machine just to make sure there wasn't something wrong with my home PC, and I was able to reproduce the issue pretty quickly. I'm at a loss for why no one else is seeing it. My work computer is a wildly different build than my home computer. The only thing they have in common besides Win 10 is they are both using NVIDIA cards.
Work specs: i7-8086K, 32GB RAM, GTX 1070
It looks like there has been a new release of BoA on Moddb: boa_c31.1.zip. Along with gzdoom-x64-g4.7.0pre-72-g250fac5b7 pulled straight from DRD extracted to an empty directory, I dropped in boa.ipk3, boa_dt.pk3, and my mapinfo.txt.
Command line: gzdoom -file boa_dt.pk3 mapinfo.txt
The mapinfo in my first post for the dev version is still valid for this "c31.1" release.
One thing I will say about doing this on my work PC, it seemed to crash only half as often as my home PC. Maybe the crash is more likely to happen the faster the PC? By the way, using the boa.exe packaged version of gzdoom, which looks to be 4.6 proper, I get no crashes on either machine.
The crash doesn't depend on anything except some internals of memory management. Randomness in allocation makes its repro rate less than 100%. At this point, any experiments are pointless as apparently we have a write to unallocated memory.
If you want to test, add | FTextureManager::TEXMAN_DontCreate right after | FTextureManager::TEXMAN_ReturnFirst in two lines I linked before. Actually, I'm pretty sure that doing this fixes the crash. The problem is, I'm still not sure that this is the best way to fix it.
That did indeed stop the crashing, and I can see by checking VRAM usage that gl_precache and the manual model texture precaching are both still working, and of course I am still able to perceive the benefit in terms of reduced gameplay stalls.
Thanks! At least this is something simple enough that I can do it myself until such time as you decide what the best course of action is.
by 0mnicydle » Sun Jun 27, 2021 11:25 am 
):
