 |
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. |
|
|
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. |
|
|
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. |
|
|
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. |
- Anonymous
