stgatilov

Maybe you can check if you can reproduce it without Frontend Acceleration. And if you can, then try also com_smp 0.

As a matter of face, I cannot reproduce the issue on High Expectations as well.

How do you cancel shot? Does the same issue happens to you on other maps?

"player1_weapon" entity usually has two attachments: so-called aimer, and arrow. In this crashdump, the aimer is here, but arrow attachment is dead: it was deleted beforehand, without clearing the attachment reference. And since this code does not check e for NULL, it calls a method on NULL object, which certainly crashes. I'll of course add a check for NULL here, but it would be interesting to understand what kills arrow attachment, and why this problem does not happen every time. UPDATE: Since everyone reported the arrow to be missing just before the crash, I suppose the real issue is that arrow entity is occasionally lost...

It can be easier to trigger on Debug build. Also, the ability to record crashdumps might depend on some Windows OS settings. You can first try to execute "crash" console command and see if you can record a crashdump from it. Just to be sure everything is prepared properly.

Yes. I think it would be even easier if you take clean 2.11 installation and record crashdump on it. This way our release PDB would match your crashdump automatically.

Here you can select configuration. The default one is "Debug" for some reason. It is interesting, because we almost never use pure Debug these days The problem is that "Debug", "Debug Editable", "Debug Fast" all use FASTLINK setting for debug information, which makes PDB file useless. Only "Release" configuration can generate crashdumps that can be passed to someone else for analysis (with PDB file of course). It looks like I can see some stack traces, and the main thread seems to "wait for frontend". It would be interesting to see what is wrong with e->spawnArgs value, but my debugger does not show anything.

Well, this is not a release build, so it is unlikely I can use my PDB. Which build it is, at least? It is near executable. It has .pdb extension.

I suppose you built your own executable. So crashdumps generated on it can only be opened with PDB file that was generated alongside it. It is possible to hack PDB file to "match" EXE file (works fine if you were using Release build of 2.11), but unfortunately it does not work for a crashdump, and I don't have your executable that crashdump was generated for. So either attach a PDB or at least EXE. If you rebuilt TDM executable after recording crashdump, then I guess crashdump is no longer openable.

The crash inside idDict access might be race condition. idDict use global string pool without mutex, so two threads cannot access it simultaneously. But the culprit is on the main thread then: frontend thread runs gameplay code which can legally access idDict-s. I will download the dump and see myself what's going on. Maybe we should add assert for threadID inside idDict/idStrPool? Maybe even leave the check enabled in release, so that if such a problem happens, it leads to Error/crash in 100% cases...

It's probably nothing more that goes wrong, and reading wrong memory by itself does not crash often (it is usually valid memory page, and depending on the build its contents can be quite deterministic). It is not the first time where such issues cause crashes on Linux while Windows build seems to work fine. Also, we might have different compile settings: Linux build settings are pretty standard, while Windows ones have e.g. security buffer checks disabled. Even calling conventions are very different between Windows and Linux. Most of C++ worshippers don't look any further than "we get undefined behavior here"

My guess would be: the door generates visual stims that AI can notice the stim has "AIUse" spawnarg which specifies its type, which is 7 = "AIUSE_DOOR" the AI code casts the stim source entity to CFrobDoor, which it is not -> crash Here is the place with non-checking cast: else if (aiUseType == EAIuse_Door) { // grayman #2866 - in the interest of reducing stim processing for closed doors, // add a check here to see if the door is closed. Otherwise, a closed door will // ping every AI w/in its radius (500) but the AI won't shut it down until it // can see the door. A guard not patrolling will receive endless pings unless // we shut it down here. CFrobDoor* door = static_cast<CFrobDoor*>(stimSource); if ( !door->IsOpen() ) { door->DisableStim(ST_VISUAL); // it shouldn't be pinging anyone until it's opened return; } Supposedly, you changed the entity C++ class from door to static entity, but did not remove the "AIUse" spawnarg. Maybe we should add IsType check here and do Error if it is incorrect.

@nbohr1more can provide you debug symbols from the assets SVN repo (for 2.11 release only, not for dev builds). They are zipped inside devel/release directory. I don't have my main PC available right now, can't do it. Then you can run "gdb ./thedarkmod.x64", within gdb execute "add-symbol-file ./thedarkmod.x64.debug", and run the program to reproduce your issue.

1.5 seconds after start is probably the time when script functions are called. Or some other post-spawn activity. Someone can also share LInux debug symbols for 2.11 release (they should be in assets repo somewhere inside devel). This way we can probably see stacktrace. Also keep in mind that the threadname message might be not the error itself, but some issue happening when game tries to throw exception or stop something after the issue has already happened.