Cleaning up BattlePlanBonuses at reset can cause a memory access violation.

[Mauller]

Edit: This was affecting both memory implementations

This occurs when having the "Search and destroy" battleplan enabled while units are alive and you exit the game.

This likely only affects the null memory implementation and has no affect on retail. This is due to the way the memory manager does not zero freed blocks of memory. So dangling pointers can still point to something that has valid data within it.

But during reset when the player lists are cleared, the game will assign a temporary team to items as the original player no longer exists. The issue is comes up when the game is trying to get the m_owningPlayer of the new team. Which should be nulled at this point but is pointing to freed memory.

Callstack when the issue occurs.

>	generalszh.exe!TeamPrototype::getControllingPlayer() Line 872	C++
 	generalszh.exe!Team::getControllingPlayer() Line 1400	C++
 	generalszh.exe!Player::getRelationship(const Team * that) Line 582	C++
 	generalszh.exe!Object::look() Line 4959	C++
 	generalszh.exe!Object::handleShroud() Line 4793	C++
 	generalszh.exe!Object::handlePartitionCellMaintenance() Line 4778	C++
 	generalszh.exe!Object::setShroudClearingRange(float newShroudClearingRange) Line 5192	C++
 	generalszh.exe!localApplyBattlePlanBonusesToObject(Object * obj, void * userData) Line 3563	C++
 	generalszh.exe!Player::removeBattlePlanBonusesForObject(Object * obj) Line 3618	C++
 	generalszh.exe!Player::becomingTeamMember(Object * obj, bool yes) Line 1092	C++
 	generalszh.exe!Object::setOrRestoreTeam(Team * team, bool restoring) Line 865	C++
 	generalszh.exe!Object::setTemporaryTeam(Team * team) Line 846	C++
 	generalszh.exe!Object::setTeam(Team * team) Line 837	C++
 	generalszh.exe!Team::~Team() Line 1378	C++
 	[External Code]	
 	generalszh.exe!MemoryPoolObject::deleteInstance() Line 113	C++
 	generalszh.exe!deleteTeamCallback(Team * o) Line 839	C++
 	generalszh.exe!TeamPrototype::removeAll_TeamInstanceList(void(*)(Team *) p) Line 675	C++
 	generalszh.exe!TeamPrototype::~TeamPrototype() Line 845	C++
 	[External Code]	
 	generalszh.exe!MemoryPoolObject::deleteInstance() Line 113	C++
 	generalszh.exe!TeamFactory::clear() Line 217	C++
 	generalszh.exe!PlayerList::reset() Line 129	C++
 	generalszh.exe!SubsystemInterfaceList::resetAll() Line 190	C++
 	generalszh.exe!GameEngine::reset() Line 721	C++
 	generalszh.exe!Win32GameEngine::reset() Line 77	C++

[Mauller]

This appears to also be happening when the pooling memory manager is enabled. So upgrading this to major.

So we have either introduced it or it was a retail bug that just happens to work fine since the game is resetting at this point.

When testing with a VC6 build it does not appear to have any external issues, such as crashing etc.

[Mauller]

This bug is occuring because of a dependency between Team objects being cleared during reset and dangling pointers being left on players relating to their default team.

When a team is destroyed the code attempts to move the players objects to another team and moves them to a NULL team during normal cleanup. This would be fine, but with some codepaths there are checks on dependencies between team relationships to determine if they are allies.

The code then looks to get the objects players default team and it will encounter the dangling pointer and pass it into the relationship checking function. Within this function there was already a null check, but since the team is never nulled it then attempts to get the controlling player from the dangling team pointer, causing a memory access exception.

Therefore during playerlist reset, we also have to clear the players default team before clearing the teamlist.