 |
@desin: Can you update the issue description and describe which pictures cause the crash, and perhaps add coordinates where in the map these pictures are located? |
 |
this four pictures causes a crash back to desktop |
 |
It's better to post this in the forum topic first so that the author of the fm can take a look first. https://forums.thedarkmod.com/index.php?/topic/19368-fan-mission-shadows-of-northdale-act-i-a-curious-mind-by-goldwell-20180323/ |
 |
This issue still persists in TDM 2.13 and the current state of the mission (from TDMs integrated mission downloader), at least on Linux. It's a pity that the darkmod executable is stripped, because this way I don't get a useful backtrace: Thread 38 "Frontend" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffba2006c0 (LWP 801168)] 0x00007ffff4ca2d29 in ?? () from /lib/x86_64-linux-gnu/libGLdispatch.so.0 (gdb) bt #0 0x00007ffff4ca2d29 in ?? () from /lib/x86_64-linux-gnu/libGLdispatch.so.0 0000001 0x0000000000b7f9ae in ?? () 0000002 0x0000000000b8d3ff in ?? () 0000003 0x0000000000b8ef0d in ?? () ... (this goes on until 0000027 which is start_thread and 0000028 which is clone3()) Update: FFS does mantis have a way to post unformatted text that does not turn #X into a link to bugreport X ? Update2: Maybe when putting a backslash before the # ? Why does Mantis not have documentation on how to format issues/comments?! Update3: No, that doesn't work either, I give up. The Mantis bugreport about this is only 15 years old (and unresolved): https://mantisbt.org/bugs/view.php?id=11763 - what a horrible piece of software. |
|
|
Solution here: https://forums.thedarkmod.com/index.php?/topic/19368-fan-mission-shadows-of-northdale-act-i-a-curious-mind-by-goldwell-20180323/page/9/#findComment-501089 |
|
|
If this happens in several FMs, the underlying problem of the crash should probably be fixed in the engine. I still haven't really understood why the crash happens (i.e. why using that shader makes the engine crash), but even if that shader should not be used or is used incorrectly or whatever that should not cause a crash. Updating the FMs probably still is a good idea, but who knows how many trigger this issue, I don't think it's feasible to play them all (on Linux) and finish each one 100% (!) to test which are affected... |
 |
The 0005012 issue has returned: https://forums.thedarkmod.com/index.php?/topic/22567-fm-down-by-the-riverside-crash-to-desktop/ https://forums.thedarkmod.com/index.php?/topic/19368-fan-mission-shadows-of-northdale-act-i-a-curious-mind-by-goldwell-20180323/page/8/#findComment-501083 But now it crashes on program deletion: #0 0x00007ffff48d5d29 in ?? () from /lib/x86_64-linux-gnu/libGLdispatch.so.0 0000001 0x0000000000be43c7 in GLSLProgram::Destroy (this=0x10fe9290) at darkmod_src/renderer/backend/GLSLProgram.cpp:61 0000002 0x0000000000bece3e in GLSLProgramManager::LoadFromGenerator(char const*, std::function<void (GLSLProgram*)> const&) (this=0x2107cc0 <programManagerInstance>, name=0x7fffb013a1f0 "ambientEnvironment", generator=...) at darkmod_src/renderer/backend/GLSLProgramManager.cpp:103 0000003 0x0000000000bec407 in GLSLProgramManager::Load (this=0x2107cc0 <programManagerInstance>, name=..., defines=...) at darkmod_src/renderer/backend/GLSLProgramManager.cpp:74 0000004 0x0000000000cc642f in GLSL_LoadMaterialStageProgram (name=0x7ffed4053f40 "ambientEnvironment") at darkmod_src/renderer/resources/Material.cpp:783 0000005 0x0000000000cc9602 in idMaterial::ParseStage (this=0x7ffed40069b0, src=..., trpDefault=TR_REPEAT) at darkmod_src/renderer/resources/Material.cpp:1568 0000006 0x0000000000ccd04e in idMaterial::ParseMaterial (this=0x7ffed40069b0, src=...) at darkmod_src/renderer/resources/Material.cpp:2470 0000007 0x0000000000ccd626 in idMaterial::Parse (this=0x7ffed40069b0, text=0x7fffb97eda30 "\n\npainting03_L\n{\n\tqer_editorimage\tmodels/darkmod/props/textures/painting03_l_d_ed\n\twood\n\n\tdiffusemap\tmodels/darkmod/props/textures/painting03_l_d\n\tbumpmap\t\tmodels/darkmod/props/textures/painting01_loc"..., textLength=1329) at darkmod_src/renderer/resources/Material.cpp:2559 #8 0x000000000049631d in idDeclLocal::ParseLocal (this=0x57c0bd0) at darkmod_src/framework/DeclManager.cpp:2318 0000009 0x000000000049263f in idDeclManagerLocal::FindType (this=0x16fdc00 <declManagerLocal>, type=DECL_MATERIAL, name=0x7ffed40c03f0 "painting03_l", makeDefault=true) at darkmod_src/framework/DeclManager.cpp:1235 0000010 0x0000000000494300 in idDeclManagerLocal::FindMaterial (this=0x16fdc00 <declManagerLocal>, name=0x7ffed40c03f0 "painting03_l", makeDefault=true) at darkmod_src/framework/DeclManager.cpp:1633 0000011 0x000000000049f3ed in idDeclSkin::Parse (this=0x7ffed4034ad0, text=0x7fffb97ee290 "\n\nportrait_with_skull02_torn\n{\nmodel models/darkmod/decorative/wall/painting01.lwo\nmodel models/darkmod/decorative/wall/painting01_m.lwo\nmodel models/darkmod/decorative/wall/painting01_l.lwo\nmodel mod"..., textLength=404) at darkmod_src/framework/DeclSkin.cpp:78 0000012 0x000000000049631d in idDeclLocal::ParseLocal (this=0x59f3e10) at darkmod_src/framework/DeclManager.cpp:2318 0000013 0x000000000049263f in idDeclManagerLocal::FindType (this=0x16fdc00 <declManagerLocal>, type=DECL_SKIN, name=0x7ffed408bc6c "portrait_with_skull02_torn", makeDefault=true) at darkmod_src/framework/DeclManager.cpp:1235 0000014 0x0000000000494382 in idDeclManagerLocal::FindSkin (this=0x16fdc00 <declManagerLocal>, name=0x7ffed408bc6c "portrait_with_skull02_torn", makeDefault=true) at darkmod_src/framework/DeclManager.cpp:1643 --Type <RET> for more, q to quit, c to continue without paging-- 0000015 0x000000000055a6bb in idEntity::Event_SetSkin (this=0x7ffed408d324, skinname=0x7ffed408bc6c "portrait_with_skull02_torn") at darkmod_src/game/Entity.cpp:7114 0000016 0x0000000000987646 in idClass::ProcessEventArgPtr (this=0x7ffed408d324, ev=0x1f5ef00 <EV_SetSkin>, data=0x7fffb97ee600) at darkmod_src/game/gamesys/Callbacks.cpp:26 0000017 0x0000000000a5a847 in idInterpreter::CallEvent (this=0x7ffed408b444, func=0x7ffff7961388, argsize=132) at darkmod_src/game/script/Script_Interpreter.cpp:817 0000018 0x0000000000a5b1f7 in idInterpreter::Execute (this=0x7ffed408b444) at darkmod_src/game/script/Script_Interpreter.cpp:1091 0000019 0x0000000000a6a0ce in idThread::Execute (this=0x7ffed408b414) at darkmod_src/game/script/Script_Thread.cpp:949 0000020 0x0000000000561c23 in idEntity::FrobAction (this=0x16762504, frobMaster=true, isFrobPeerAction=false) at darkmod_src/game/Entity.cpp:9544 0000021 0x000000000067d033 in idPlayer::PerformFrob (this=0x156bf4e4, impulseState=EPressed, target=0x16762504, allowUseCurrentInvItem=true) at darkmod_src/game/Player.cpp:11843 0000022 0x000000000067d916 in idPlayer::PerformFrob (this=0x156bf4e4) at darkmod_src/game/Player.cpp:12047 0000023 0x000000000066884c in idPlayer::PerformImpulse (this=0x156bf4e4, impulse=41) at darkmod_src/game/Player.cpp:5935 0000024 0x00000000006696f4 in idPlayer::EvaluateControls (this=0x156bf4e4) at darkmod_src/game/Player.cpp:6347 0000025 0x000000000066e72d in idPlayer::Think (this=0x156bf4e4) at darkmod_src/game/Player.cpp:7616 0000026 0x00000000005ba9dd in idGameLocal::RunFrame (this=0x16b3a40 <gameLocal>, clientCmds=0x7fffb97eebe0, timestepMs=17, minorTic=false) at darkmod_src/game/Game_local.cpp:3397 0000027 0x00000000004cac3c in idSessionLocal::RunGameTic (this=0x17055a0 <sessLocal>, timestepMs=17, minorTic=false) at darkmod_src/framework/Session.cpp:2997 0000028 0x00000000004cb020 in idSessionLocal::RunGameTics (this=0x17055a0 <sessLocal>) at darkmod_src/framework/Session.cpp:3043 0000029 0x00000000004cb291 in idSessionLocal::FrontendThreadFunction (this=0x17055a0 <sessLocal>) at darkmod_src/framework/Session.cpp:3104 0000030 0x00000000004cb6bc in operator() (__closure=0x0, x=0x17055a0 <sessLocal>) at darkmod_src/framework/Session.cpp:3186 0000031 0x00000000004cb6e4 in _FUN () at darkmod_src/framework/Session.cpp:3188 0000032 0x00007ffff769caa4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447 0000033 0x00007ffff7729c3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 It happens when player frobs e.g. a painting atdm_loot_painting_medium_4 in Northdal1 mission. In this case the painting is dynamically replaced with an torn painting using a skin "angel_with_skulls_torn". This skin references a material which is not used directly in the map, but used only via such a replacement. For that reason the material was not preloaded during level start. When the material is parsed, it parses custom shader stage (inside ambient stages, which are already dead BTW). At this moment, the GLSLProgram gets updated despite the fact it already exists. While this update does not immediately create anything GL-ish, it does delete the old program: GLSLProgram * GLSLProgramManager::LoadFromGenerator( const char *name, const Generator &generator ) { GLSLProgram *program = Find( name ); if( program != nullptr ) { program->SetGenerator( generator ); if( renderSystem->IsOpenGLRunning() ) { program->Destroy(); } return program; } The questions I have right now: 1) Do we really need to reset generator and recreate program in this case, why not leave existing program as is? Either the GLSLProgramManager method or the GLSL_LoadMaterialStageProgram function should check that shader already exists and not do anything. 2) What about CPU-side thread safety when frontend tries to add/modify a shader? Given that GLSL systems are normally accessed by backend, doesn't it cause race condition? |
|
|
1) If it turns out that the program must really be recreated, I'd suggest setting the generator and a flag in GLSLProgram for "it must be destroyed and recreated", so the backend (main thread) can destroy the old one and call the generator function at a convenient time (next time it tries to use it?) 2) Looks like that could theoretically happen? For adding a shader it's probably quite unlikely, because it doesn't look like the frontend accesses the programs array a lot (and the existing shader objects aren't affected by another one being added), but I guess access to that array could be guarded by a mutex (to avoid unlikely cases)? If an existing GLSLProgram must indeed be modified, then there might be race conditions, but again seems unlikely (once fix from 1) is applied): The generator function seems to be accessed very rarely (but could also be guarded by a mutex, maybe even a global one) and if a flag for "destroy and recreate me" is really necessary, it could be made atomic |
|
|
I think the more correct approach would be to cut it at GLSL_LoadMaterialStageProgram. Instead of eagerly updating GLSL programs from frontend, pass information that idMaterial with given name should get GLSL programs reloaded. When backend runs, check the list with this information, do GLSL update, and assign pointer into idMaterial. |
|
|
You know the code better than I do, so you're probably right :) |
- Anonymous
