View Issue Details

IDProjectCategoryView StatusLast Update
0006225The Dark ModCodingpublic19.01.2023 12:53
Reporterstgatilov Assigned Tostgatilov  
PrioritynormalSeveritycrashReproducibilityrandom
Status resolvedResolutionfixed 
Product VersionTDM 2.10 
Target VersionTDM 2.11Fixed in VersionTDM 2.11 
Summary0006225: Crash during melee combat in training mission
DescriptionWhen doing melee training in Training Mission, the game sometimes crashes.
This is very hard to reproduce: most likely needs killing guard at particular moment (e.g. when parrying), and also might involve one guard trying to push another one, etc.
Steps To Reproduce1) Start Training Mission.
2) Go to Melee area and fight until it crashes =)
TagsNo tags attached.

Activities

stgatilov

stgatilov

10.01.2023 20:11

administrator   ~0015747

I managed to reproduce this crash after 10-15 fights on Debug build (with gflags's Page Heap, but I don't think it matters).
I got it on two-man fight (which might be important).

Here is stack trace:
     TheDarkModx64.exe!idClass::IsType(const idTypeInfo & superclass) Line 334 C++
> TheDarkModx64.exe!idAI::PushWithAF() Line 8962 C++
     TheDarkModx64.exe!idAI::Think() Line 2692 C++
     TheDarkModx64.exe!idGameLocal::RunFrame(const usercmd_t * clientCmds, int timestepMs, bool minorTic) Line 3366 C++
     TheDarkModx64.exe!idSessionLocal::RunGameTic(int timestepMs, bool minorTic) Line 3061 C++
     TheDarkModx64.exe!idSessionLocal::RunGameTics() Line 3107 C++
     TheDarkModx64.exe!idSessionLocal::FrontendThreadFunction() Line 3157 C++
     TheDarkModx64.exe!idSessionLocal::StartFrontendThread::__l2::<lambda>(void * x) Line 3233 C++
     TheDarkModx64.exe!unsigned int <lambda>(void *)::<lambda_invoker_cdecl>(void * x) Line 3234 C++

In the following code in PushWithAF:
    idClip_afTouchList touchList;
    int num = af.EntitiesTouchingAF( touchList );
    for( i = 0; i < num; i++ ) {
        if ( touchList[ i ].touchedEnt->IsType( idProjectile::Type ) ) {
We get broken touchList[i] among others.

It has valid member "touchedByBody", which points to "rlowarm" body of trainerguard3_314 (that's the "this" pointer in PushWithAF call).
The member "touchedClipModel" seems to point to a seemingly valid idClipModel object with contents = CONTENTS_MELEEWEAP.
Quite interestingly, if I find this clip model in idClip's octree, the node which contains it seems to be corrupted (numSmall = -6, which must be nonnegative).
Also, "touchedEnt" points to zeroed memory: I think that is dangling pointer to an already deleted idEntity which has been reused for totally unrelated data (and thus zeroed).

I'll add assert for numSmall >= 0 and check why it goes negative, but I think it is merely the consequence.
CONTENTS_MELEEWEAP is a very rare content bit, only used in CMeleeWeapon entity.
I think CMeleeWeapon creates such a clipmodel but then dies.
And when CMeleeWeapon dies, it does not kill the clipmodel: it continues to live in idClip and can become a result of collision query, at which point looking at entity quite likely crashes.
stgatilov

stgatilov

10.01.2023 20:12

administrator   ~0015749

Also I think I saw this crash many times.
I think I usually see it when I spawn horde of various AIs on the Arena mission, but I'm not sure.
stgatilov

stgatilov

13.01.2023 19:07

administrator   ~0015770

CMeleeWeapon creates custom clipmodel m_WeapClip temporarily:
  1) For the brief time when the actual slash happens (it is much shorter than the visible swing, usually activates briefly at the time you get a blow or parry).
  2) For the parrying time.
It happens both for AI and player.

If the entity dies at this moment, then the clipmodel is left in idClip.
Also, if player saves at this moment, then clipmodel is not properly restored on load.
stgatilov

stgatilov

13.01.2023 21:39

administrator   ~0015771

In the end, I noticed that when creating a new clipmodel for m_WeapClip, the old one is still present and it leaks.

So, here is a bunch of commits fixing the issue:
  r10241 Deleted old code in CMeleeWeapon, dead at least since 2010.
  r10242 Deleted m_bClipAxAlign member (it is always true).
  r10243 Assert that we don't leak clipmodel.
  r10244 Fixed clipmodel leak issue.
  r10245 Deleted m_bModCM in CMeleeWeapon (always false), fixed save/restore for custom clipmodel.

The fix is actually in r10244, the rest is mostly cleaning.

Issue History

Date Modified Username Field Change
10.01.2023 20:03 stgatilov New Issue
10.01.2023 20:03 stgatilov Status new => assigned
10.01.2023 20:03 stgatilov Assigned To => stgatilov
10.01.2023 20:11 stgatilov Note Added: 0015747
10.01.2023 20:12 stgatilov Note Added: 0015749
13.01.2023 19:07 stgatilov Note Added: 0015770
13.01.2023 21:39 stgatilov Note Added: 0015771
13.01.2023 21:39 stgatilov Status assigned => feedback
13.01.2023 21:39 stgatilov Fixed in Version => TDM 2.11
13.01.2023 21:39 stgatilov Target Version TDM 2.12 => TDM 2.11
19.01.2023 12:53 nbohr1more Status feedback => resolved
19.01.2023 12:53 nbohr1more Resolution open => fixed