View Issue Details

IDProjectCategoryView StatusLast Update
0004952The Dark ModCodingpublic02.02.2019 21:43
ReporterThrashaero Assigned ToSTiFU  
Status resolvedResolutionfixed 
Platformx64OSWindows 7OS Versionx64
Product VersionTDM 2.06 
Target VersionTDM 2.07Fixed in VersionTDM 2.07 
Summary0004952: Training mission - Melee - Crash during retry
DescriptionAfter every dozen or so retries, upon death, I get a crash to desktop, here is the info I get so far from the crash window:

Problem signature:
  Problem Event Name: APPCRASH
  Application Name: TheDarkModx64.exe
  Application Version:
  Application Timestamp: 5afd6d41
  Fault Module Name: TheDarkModx64.exe
  Fault Module Version:
  Fault Module Timestamp: 5afd6d41
  Exception Code: c0000005
  Exception Offset: 000000000032067b
  OS Version: 6.1.7601.
  Locale ID: 1033
  Additional Information 1: de15
  Additional Information 2: de15fc983bd2fc0e89ee2406257e2883
  Additional Information 3: 2b17
  Additional Information 4: 2b17918e1fd4f7fa8f610ebe580fcac0

Read our privacy statement online:

If the online privacy statement is not available, please read our privacy statement offline:
Steps To ReproduceTry melee and die several times and CTD, clicking to continue
Additional InformationI am wholly impressed with the training mission. It feels better than the original games by a long shot, fairly thorough and excellent level of detail. The melee area is the only one I've had consistent trouble with.
TagsNo tags attached.


related to 0004959 closedSpringheel Thrashaero TDM forum account 




09.01.2019 07:04

reporter   ~0011266

I get the exact same problem signature every time. It is upon death and I'm trying to click to swing/continue then CTD.


09.01.2019 15:45

developer   ~0011269

Please verify whether this happens in 2.07 beta:


10.01.2019 20:15

developer   ~0011304

I can reproduce this bug on latest SVN. When the player dies, all AI searches are discontinued. There are pointers to AI maintained whose searches are supposed to be ended and that pointer points to inconclusive data. I assume the AI has already been destroyed (it is despawned right?) and we get a memory access violation when trying to make that AI leave the search. I'll see if I can convert those pointers to Weak pointers, to ensure we only access them if the AI has not yet been destroyed.

Here is the callstack:
TheDarkModx64.exe!idVec3::operator=(const idVec3 & a={...}) Line 422
TheDarkModx64.exe!CSearchManager::LeaveSearch(int searchID=15, idAI * ai=0x000002800aefccf4) Line 1532
TheDarkModx64.exe!CSearchManager::ProcessSearches() Line 2189
TheDarkModx64.exe!idGameLocal::RunFrame(const usercmd_t * clientCmds=0x000000db83ffec18) Line 3464
TheDarkModx64.exe!idSessionLocal::RunGameTic() Line 2955
TheDarkModx64.exe!idSessionLocal::RunGameTics() Line 3024
TheDarkModx64.exe!idSessionLocal::FrontendThreadFunction() Line 3070


10.01.2019 20:41

developer   ~0011305

Ok, adding a Shared pointer / weak pointer construct is no option here, as that would penetrate the whole code base. What is also weird is that my breakpoint in
  // If the player is dead, all searchers should leave their searches.
  if (player->health <= 0)
isn't always hit, which means that the search must've been canceled earlier already, or something like that.

I am thinking about actively Leaving the search from the Destructor of idAi.


10.01.2019 21:19

developer   ~0011306

Yes, the search is canceled earlier, when the AI enters combat state.

I am still not 100% sure the AI is destroyed before LeaveSearch() was called. If that is the case, the fix is easy: Add the following to ~idAi()
  if (m_searchID >= 0)
    CSearchManager::Instance()->LeaveSearch(m_searchID, this);

I will add logging to the destructor of idAi and LeaveSearch, to investigate the timing without the debugger attached.


10.01.2019 22:28

developer   ~0011307

This issue occurs very rarely. For now, I give up finding proof that it is in fact trying to LeaveSearch() for an already destroyed AI, which I think is very likely. In case of the training mission, neither idAi::Killed() nor idAi::Knockout() are called. Both of these methods would properly call LeaveSearch(). Here, the AI is simply destroyed and the destructor does not have the LeaveSearch(), so adding the above two lines would generally be a good safety measure, regardless of whether this is the true cause of the issue or not.


10.01.2019 22:30

developer   ~0011309

Last edited: 10.01.2019 22:39

View 2 revisions

I still wonder why there is sometimes a search active although the AI who just beat me was in combat state. Could it be a timing issue?



11.01.2019 14:46

administrator   ~0011320

Is the issue that when LeaveSearch() runs, its 'ai' argument is NULL?

If so, why not just test for NULL and exit early if that's the case.


11.01.2019 14:51

developer   ~0011321

No, ai is not NULL, but the data pointed to is trash, probably because the AI has been destroyed already. Hence, my proposal to actively LeaveSearch() in the destructor of idAi.


11.01.2019 15:18

administrator   ~0011322

Well, that should work.

I suppose the only time AI are destructed are at the end of the mission when everything gets destructed, or in the Training Mission. I've never battled the TM guys, so was unaware that they were destructed rather than killed.


13.01.2019 15:55

developer   ~0011347

After running an admittedly simple automation script for two hours, where I teleport into the fighting pit and wait until the AI kills me, I still couldn't reproduce this bug again. The AI killed me about 400 times. So, either this is not the right way to reproduce this issue or it is incredibly rare.

I will commit my proposed fix and wait for further reports regarding this issue.


13.01.2019 20:33

reporter   ~0011350

Last edited: 20.01.2019 21:30

View 3 revisions

The night I reported the bug, I ran into it about 7-8 times. It seemed to be while I was holding keys/mouse button as well.



15.01.2019 02:32

developer   ~0011357

2.07 beta 6 will include the latest fix.
We will await further confirmation then.


22.01.2019 12:22

developer   ~0011470

Fix deemed too risky for 2.07. Moving to 2.08.


26.01.2019 06:30

administrator   ~0011505

I tried to revert the change locally, and failed to reproduce it after that.
Maybe it depends on some settings... Unless 0004839 gets fixed, fighting with uncapped FPS is rather broken.


26.01.2019 07:24

developer   ~0011507

Yes, this bug is incredibly rare. FYI, I have all graphical features enabled or the more advanced options chosen.

Issue History

Date Modified Username Field Change
09.01.2019 06:35 Thrashaero New Issue
09.01.2019 07:04 Thrashaero Note Added: 0011266
09.01.2019 15:45 nbohr1more Note Added: 0011269
10.01.2019 20:15 STiFU Note Added: 0011304
10.01.2019 20:15 STiFU Assigned To => STiFU
10.01.2019 20:15 STiFU Status new => assigned
10.01.2019 20:41 STiFU Note Added: 0011305
10.01.2019 21:19 STiFU Note Added: 0011306
10.01.2019 22:28 STiFU Note Added: 0011307
10.01.2019 22:30 STiFU Note Added: 0011309
10.01.2019 22:39 STiFU Note Edited: 0011309 View Revisions
11.01.2019 07:04 STiFU Status assigned => feedback
11.01.2019 14:46 grayman Note Added: 0011320
11.01.2019 14:51 STiFU Note Added: 0011321
11.01.2019 15:18 grayman Note Added: 0011322
11.01.2019 23:00 Thrashaero Status feedback => assigned
13.01.2019 15:55 STiFU Note Added: 0011347
13.01.2019 15:56 STiFU Status assigned => feedback
13.01.2019 15:56 STiFU Resolution open => fixed
13.01.2019 15:56 STiFU Target Version => TDM 2.07
13.01.2019 20:33 Thrashaero Note Added: 0011350
13.01.2019 20:33 Thrashaero Status feedback => assigned
13.01.2019 22:55 Thrashaero Note Edited: 0011350 View Revisions
15.01.2019 02:32 nbohr1more Note Added: 0011357
15.01.2019 02:32 nbohr1more Status assigned => feedback
16.01.2019 18:09 Thrashaero Status feedback => assigned
16.01.2019 18:42 nbohr1more Relationship added related to 0004959
16.01.2019 18:44 nbohr1more Status assigned => feedback
16.01.2019 18:47 Thrashaero Status feedback => assigned
16.01.2019 18:48 nbohr1more Status assigned => feedback
20.01.2019 21:30 STiFU Note Edited: 0011350 View Revisions
22.01.2019 12:22 nbohr1more Note Added: 0011470
22.01.2019 12:23 nbohr1more Target Version TDM 2.07 => TDM 2.08
26.01.2019 06:30 stgatilov Note Added: 0011505
26.01.2019 07:24 STiFU Note Added: 0011507
27.01.2019 09:09 stgatilov Target Version TDM 2.08 => TDM 2.07
02.02.2019 21:43 nbohr1more Status feedback => resolved
02.02.2019 21:43 nbohr1more Fixed in Version => TDM 2.07