View Issue Details

IDProjectCategoryView StatusLast Update
0005433The Dark ModCodingpublic06.01.2021 14:34
Reporterduzenko Assigned Tostgatilov  
PrioritynormalSeveritynormalReproducibilityrandom
Status resolvedResolutionfixed 
PlatformPCOSWindowsOS Version10
Product VersionSVN 
Target VersionTDM 2.09Fixed in VersionTDM 2.09 
Summary0005433: Random crash when dynamically loading textures
DescriptionNavigating to a new location in game triggered this crash

Additional InformationApprox view org: (-1785 367 -60)

image.imgName: tdm_beggar_sleeves

image.loadStack: attached as screenshot

Stack trace

     [Inline Frame] TheDarkModx64NoTools.exe!idHashIndex::First(const int) Line 226 C++
     TheDarkModx64NoTools.exe!idDict::FindKey(const char * key=0x00007ff704bb645c) Line 446 C++
     [Inline Frame] TheDarkModx64NoTools.exe!idDict::GetString(const char *) Line 230 C++
     TheDarkModx64NoTools.exe!LoadStack::Level::Print(int indent) Line 89 C++
     TheDarkModx64NoTools.exe!LoadStack::PrintStack(int indent=2, const LoadStack::Level & addLastLevel={...}) Line 64 C++
> TheDarkModx64NoTools.exe!R_UploadImageData(idImage & image={...}) Line 1264 C++
     TheDarkModx64NoTools.exe!idImage::Bind() Line 1417 C++
     TheDarkModx64NoTools.exe!RB_BindVariableStageImage(const textureStage_t * texture, const float * shaderRegisters) Line 607 C++
     TheDarkModx64NoTools.exe!RB_STD_T_RenderShaderPasses_OldStage(const shaderStage_t * pStage=0x000001e752b48c30, const drawSurf_s * surf=0x000001e7329c3080) Line 523 C++
     TheDarkModx64NoTools.exe!RB_STD_T_RenderShaderPasses(const drawSurf_s * surf=0x000001e7329c3080) Line 836 C++
     TheDarkModx64NoTools.exe!RB_STD_DrawShaderPasses(drawSurf_s * * drawSurfs=0x000001e732970a50, int numDrawSurfs=64) Line 942 C++
     TheDarkModx64NoTools.exe!RB_STD_DrawView() Line 1282 C++
     TheDarkModx64NoTools.exe!RB_DrawView() Line 1143 C++
     TheDarkModx64NoTools.exe!RB_ExecuteBackEndCommands(const emptyCommand_t * cmds=0x000001e7329d9180) Line 832 C++
     TheDarkModx64NoTools.exe!R_IssueRenderCommands(frameData_t * frameData=0x00007ff705fdb240) Line 142 C++
     TheDarkModx64NoTools.exe!idRenderSystemLocal::EndFrame(int * frontEndMsec=0x0000000000000000, int * backEndMsec=0x0000000000000000) Line 641 C++
     TheDarkModx64NoTools.exe!idSessionLocal::UpdateScreen(bool outOfSequence) Line 2759 C++
     TheDarkModx64NoTools.exe!idCommonLocal::Frame() Line 2544 C++
     TheDarkModx64NoTools.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance=0x0000000000000000, char * lpCmdLine=0x000001e725565727, int nCmdShow=0) Line 1321 C++
     [External Code]
TagsNo tags attached.
Attached Files
image.png (49,506 bytes)   
image.png (49,506 bytes)   

Relationships

related to 0005170 resolvedstgatilov Fix console warnings 
related to 0005487 resolvedcabalistic "image_preload 0" breaks rendering if SSAO or Bloom are enabled 

Activities

duzenko

duzenko

27.11.2020 18:43

developer   ~0013043

Can't reproduce but can see the error in console: couldn't load image and a stack printout
stgatilov

stgatilov

05.12.2020 13:08

administrator   ~0013102

Most likely a dangling pointer issue.
It would be great to see crash dump for this (on some version with debug symbols).
duzenko

duzenko

06.12.2020 15:07

developer   ~0013106

I run SVN no-tools builds, so no debug symbols
How do I build those locally?
I think I should close this one for now? Since it's not reproducible and it's not a beta testing stage yet
nbohr1more

nbohr1more

05.01.2021 05:46

developer   ~0013366

What mission?
duzenko

duzenko

05.01.2021 10:09

developer   ~0013371

Last edited: 05.01.2021 10:10

All missions, image_preload 0, happens after 10-20 minutes of gameplay
I worked around it locally with decl_stack 0
nbohr1more

nbohr1more

06.01.2021 02:11

developer   ~0013390

I asked which mission since you supplied coordinates:

Approx view org: (-1785 367 -60)

That said, I have not had a crash like this except for the r_useParallelAddModels which I no longer have as of 2.09 beta.

So you are trying to run without: image_preload "1" ? To save on VRAM? I'll try to reproduce with that setting.
nbohr1more

nbohr1more

06.01.2021 03:42

developer   ~0013392

"image_preload 0" is seriously broken now.

The only way to see anything after the mission is started is to "reloadImages" which I presume does exactly what "image_preload 1" would do.
If we aren't going to fix this, then the cvar should be un-archived.
stgatilov

stgatilov

06.01.2021 04:27

administrator   ~0013393

Oh yes, this use case is of course broken.

I'll change the loadStack to store strings internally.
stgatilov

stgatilov

06.01.2021 12:19

administrator   ~0013397

Now LoadStack saves all strings (i.e. names) immediately when new object is appended onto stack.
The printout code now use the saved strings.
In fact, object pointer is never used now: it remains for debugging purposes only. The object can die after Append without any problem.

All the strings are stored in a global pool (idStrPool), similar to the ones used for keys/values in idDict.
Commands like showLoadStackMemory allow to see how much space is taken by them right now.

The list of commits:
  r9065. Reverted commit 8947 (hack around dangling pointer to idWindow).
  r9066. idStrPool refactoring (use cpp file, extracted strings printing code).
  r9067. LoadStack now extracts strings immediately in Append and stores them in its own global pool. This should fix all sort of dangling pointers, since object pointers are never dereferenced.
The r9066 has no effect, just some generic refactoring.
r9067 has the main changes, and r9065 reverts some hack which is no longer needed.
stgatilov

stgatilov

06.01.2021 12:21

administrator   ~0013398

These changes fix the loadstack crash, but "image_preload 0" still does not work for me.
At least on default settings. The whole screen is gray.

Maybe caused by bindless textures, don't know.

Issue History

Date Modified Username Field Change
27.11.2020 18:36 duzenko New Issue
27.11.2020 18:36 duzenko File Added: image.png
27.11.2020 18:41 duzenko Additional Information Updated
27.11.2020 18:41 duzenko Additional Information Updated
27.11.2020 18:43 duzenko Note Added: 0013043
05.12.2020 13:08 stgatilov Note Added: 0013102
06.12.2020 15:07 duzenko Note Added: 0013106
05.01.2021 05:46 nbohr1more Note Added: 0013366
05.01.2021 10:09 duzenko Note Added: 0013371
05.01.2021 10:10 duzenko Note Edited: 0013371
06.01.2021 02:11 nbohr1more Note Added: 0013390
06.01.2021 03:42 nbohr1more Note Added: 0013392
06.01.2021 04:27 stgatilov Note Added: 0013393
06.01.2021 04:28 stgatilov Assigned To => stgatilov
06.01.2021 04:28 stgatilov Status new => assigned
06.01.2021 06:13 stgatilov Relationship added related to 0005170
06.01.2021 12:19 stgatilov Note Added: 0013397
06.01.2021 12:21 stgatilov Note Added: 0013398
06.01.2021 12:22 stgatilov Status assigned => resolved
06.01.2021 12:22 stgatilov Resolution open => fixed
06.01.2021 12:22 stgatilov Fixed in Version => TDM 2.09
06.01.2021 14:34 nbohr1more Relationship added related to 0005487