View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005433 | The Dark Mod | Coding | public | 27.11.2020 18:36 | 06.01.2021 14:34 |
Reporter | duzenko | Assigned To | stgatilov | ||
Priority | normal | Severity | normal | Reproducibility | random |
Status | resolved | Resolution | fixed | ||
Platform | PC | OS | Windows | OS Version | 10 |
Product Version | SVN | ||||
Target Version | TDM 2.09 | Fixed in Version | TDM 2.09 | ||
Summary | 0005433: Random crash when dynamically loading textures | ||||
Description | Navigating to a new location in game triggered this crash | ||||
Additional Information | Approx 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] | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
related to | 0005170 | resolved | stgatilov | Fix console warnings |
related to | 0005487 | resolved | cabalistic | "image_preload 0" breaks rendering if SSAO or Bloom are enabled |
Can't reproduce but can see the error in console: couldn't load image and a stack printout | |
Most likely a dangling pointer issue. It would be great to see crash dump for this (on some version with debug symbols). |
|
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 |
|
What mission? | |
All missions, image_preload 0, happens after 10-20 minutes of gameplay I worked around it locally with decl_stack 0 |
|
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. |
|
"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. |
|
Oh yes, this use case is of course broken. I'll change the loadStack to store strings internally. |
|
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. |
|
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. |
|
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 |