Game crashed after a flame drop with chinooks

[DrGoldFish1]

Prerequisites

• I have searched for similar issues and confirmed this is not a duplicate

Game Version

• Command & Conquer Generals
• Command & Conquer Generals: Zero Hour
• Other (please specify below)

Bug Description

Did not test this in generals.

On legionnaire stream, he did a flamer drop with the use of chinooks.
He dropped of the flamers then a crash seem to happen when a chinook dies.
I did try to replicate this bug with no luck.

The game keeps on crashing if you watch the replay.

Reproduction Steps

Don`t know how to replicate this.

The game will crash if you rewatch the replay and go to the exact frame 00:19:03:28

replay is in the zip file
06 Defcon 6 FFA - Nuke General.zip

Additional Context

[Mauller]

Got a partial preliminary report on this by running latest main VC6 build with windbg. will try running debug build to see if it tracks it down better.

(457c.2b84): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=1d3c132c ecx=1d3c130c edx=00000000 esi=1d3c130c edi=1d3c130c
eip=005c07f1 esp=0019f9a4 ebp=00000001 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
generalszh!AIUpdateInterface::privateMoveAwayFromUnit+0x41:
005c07f1 8b4a64          mov     ecx,dword ptr [edx+64h] ds:002b:00000064=????????

[Mauller]

callstack

[0x13]   generalszh!AIUpdateInterface::privateMoveAwayFromUnit+0x41   0x19f9a4   0x5c024a   
[0x14]   generalszh!AIUpdateInterface::aiDoCommand+0x55a   0x19f9bc   0x637d6e   
[0x15]   generalszh!HackInternetAIUpdate::aiDoCommand+0x4e   0x19f9d4   0x637c97   
[0x16]   generalszh!HackInternetAIUpdate::update+0x77   0x19f9e8   0x49ab91   
[0x17]   generalszh!GameLogic::update+0x2a1   0x19fa98   0x714749   
[0x18]   generalszh!Win32GameEngine::update+0x9   0x19fad4   0x40fb4a   
[0x19]   generalszh!GameEngine::execute+0x4a   0x19fae0   0x40e303   
[0x1a]   generalszh!GameEngine::init+0x23   0x19faf0   0x412d56   
[0x1b]   generalszh!GameMain+0x26   0x19fb10   0x401bad   
[0x1c]   generalszh!WinMain+0x45d   0x19fb14   0x8a2292   

[Mauller]

There is a possibility that the parent state machine is getting nuked at this point.

[Mauller]

Game should be returning INVALID_STATE_ID

StateID getCurrentStateID() const { return m_currentState ? m_currentState->getID() : INVALID_STATE_ID; }

posibility that the state machine handle is nuked at this point, but where it is being fixed in xezons branch does not fix this particular issue.

[Mauller]

Turns out the issue is related to a null pointer access due to not checking that the unit param is valid.

[Mauller]

So at the point this crashes we appear to be acting on an invalid / incomplete command to move away from something without the actual details being entered.

as there is no m_obj populated, the privateMoveAwayFromUnit() function is performing an illegal operation on a null pointer to retrieve the object id.

[Mauller]

Something interesting about this is that i put code to return from functions that would call aiMoveAwayFromUnit() to make sure that a valid object is passed into the function.

The aiMoveAwayFromUnit function is the only one that appears to set a command for AICMD_MOVE_AWAY_FROM_UNIT which is what is being acted upon at the point the game crashes in the replay.

Looking a little more and the weird thing is that the passed command seems to get it's contents nuked somehow but the data from the original is still fine in the object the command came from. But this also depends on if the callstack is correct etc.

[Mauller]

I think i have figured out the issue now.

So what can happen is that objects can receive delayed commands and it appears that the command was initially valid but then became invalid when finally processed due to the original object the move command related to being destroyed before the pending command could be acted upon.

So the command gets "reconstituted" and the object pointer returned within the the "AICommandParms" was a NULL due to the object no longer existing.

Since the privateMoveAwayFromUnit function was not checking if the unit parameter was a valid pointer, it then tried to call a function on a null pointer and caused the crash.

The fix here might be to just check the unit parameter is not null before acting on it in the privateMoveAwayFromUnit function. Some commands do not make use of the objectID call so we cannot guarantee that it will always be present for the pendingCommand. So acting on it too soon might casue problems with other commands that will always have the object pointer nulled.

The pending command on the problematic object

The AICommandParms produced when it is "reconstituted"

The AICommandParmsStorage::reconstitute function is what is then finding the relevant object and placing the nullptr into the AIcommandParms object.

void AICommandParmsStorage::reconstitute(AICommandParms& parms) const
{
	parms.m_cmd = m_cmd;
  parms.m_cmdSource = m_cmdSource;
  parms.m_pos = m_pos;
  parms.m_obj = TheGameLogic->findObjectByID(m_obj);
  parms.m_otherObj = TheGameLogic->findObjectByID(m_otherObj);
  parms.m_team = TheTeamFactory->findTeam(m_teamName);
	parms.m_coords = m_coords;
  parms.m_waypoint = m_waypoint;
  parms.m_polygon = m_polygon;
  parms.m_intValue = m_intValue;
  parms.m_damage = m_damage;
	parms.m_commandButton = m_commandButton;
	parms.m_path = m_path;	/// @todo srj -- probably need a better way to safely save/restore this
}