Crash to desktop, with recurring error code in .dmp file

Re-loader

Warlord
Joined
Feb 12, 2007
Messages
149
Well, I suppose this is a sort of a work in progress. I decided to do some experimenting, and tried to compile(release) a .dll with the pTheirNearestCity initialised, and it still crashes.
Gonna have a break from it for a bit and will upload some data related to the crash later on today.

Edit: With dave uk's dll it doesn't crash, and that's with the initialisation mentioned above,
 
Last edited:

f1rpo

plastics
Joined
May 22, 2014
Messages
1,422
Location
Germany
I decided to do some experimenting, and tried to compile(release) a .dll with the pTheirNearestCity initialised, and it still crashes.
Could be a different cause maybe. But if you compile a debug DLL from the same source (i.e. with pNearestCity initialized), there is no crash?
Then the turn completed. :confused:
And the crash with the release DLL is consistently reproducible while the debug DLL never crashes (on that particular turn)? That could be, or maybe it's just crashing randomly with both builds.
So I replaced the VS dll with the standard dave uk dll, tried the turn again, and no crash.
But that DLL had been crashing before, and you haven't changed anything about it? Or ... I guess we're talking about a different turn/ savegame now.
Edit: With dave uk's dll it doesn't crash, and that's with the initialisation mentioned above,
I thought dave's DLL, just with pTheirNearestCity=NULL (and re-compiled for the change to take effect) is what crashes. 🙃
And which team is that? Does it have cities? Assuming that each team has only one member, no player has been defeated and it's not a scenario, the positioning on the Foreign Advisor should correspond to the ID, i.e. the human civ in the first slot (ID 0), then increasing IDs from left to right. That's eTeam, I assume. May also need to know
m_eID under "this" --> "CvTeam" in the Locals window
to really figure out what's going on, i.e. why that latter team is apparently unable to locate cities of team 11 (not even when cheating with map knowledge).
Hovering over the text you mentioned revealed nothing. Looking in the tabs under (locals, auto, etc) provided a lot of info, but as you thought this was possibly not the cause of the crash, I left it and waited for another break.
I guess that makes sense; the debugger doesn't keep track of the node returned by the headMissionQueueNode() function. Could insert a variable above the switch block
MissionTypes eTmp = headMissionQueueNode()->m_data.eMissionType;
then recompile, choose Debug when the assertion fails and then hover over eTmp (or find it in the Locals window). That would be just a temporary change to diagnose the problem. But I'd agree that it's not a priority.
CvTeamAI.cpp Line 6566 bShareValid not defined
Runtime check failure #3 variable 'bShareValid' is being used without being defined.
Sheesh, dave has introduced a lot of those errors. Also the one I came across in my brief debugging session:Though the convention of declaring all variables at the start of a function – surely already widely discouraged at the time – is really Firaxis's fault. So, bShareValid gets declared at the start of CvTeamAI::AI_doWar, but is only initialized and supposed to be used in this if block:
Spoiler :
Code:
if (AI_getWarPlanStateCounter((TeamTypes)iI) > ((10 * iTimeModifier) / (bEnemyVictoryLevel4 ? 400 : 100)))
{
	bAreaValid = false;
	bShareValid = false;

	for(pLoopArea = GC.getMapINLINE().firstArea(&iLoop); pLoopArea != NULL; pLoopArea = GC.getMapINLINE().nextArea(&iLoop))
	{
		if (AI_isPrimaryArea(pLoopArea))
		{
			if (GET_TEAM((TeamTypes)iI).countNumCitiesByArea(pLoopArea) > 0)
			{
				bShareValid = true;

				AreaAITypes eAreaAI = AI_calculateAreaAIType(pLoopArea, true);

				if ( eAreaAI == AREAAI_DEFENSIVE)
				{
					bAreaValid = false;
				}
				else if( eAreaAI == AREAAI_OFFENSIVE )
				{
					bAreaValid = true;
				}
			}
		}
	}

	if ( (bAreaValid && (iEnemyPowerPercent < 140)) || (!bShareValid && (iEnemyPowerPercent < 110)) || (GET_TEAM((TeamTypes)iI).AI_getLowestVictoryCountdown() >= 0) )
	{
		if( gTeamLogLevel >= 1 )
		{
			logBBAI("      Team %d (%S) switching WARPLANS against team %d (%S) from PREPARING_TOTAL to TOTAL after %d turns with enemy power percent %d", getID(), GET_PLAYER(getLeaderID()).getCivilizationDescription(0), iI, GET_PLAYER(GET_TEAM((TeamTypes)iI).getLeaderID()).getCivilizationDescription(0), AI_getWarPlanStateCounter((TeamTypes)iI), iEnemyPowerPercent );
		}
		AI_setWarPlan(((TeamTypes)iI), WARPLAN_TOTAL);
	}
	else if (AI_getWarPlanStateCounter((TeamTypes)iI) > ((20 * iAbandonTimeModifier) / 100))
	{
		if( gTeamLogLevel >= 1 )
		{
			logBBAI("      Team %d (%S) abandoning WARPLAN_TOTAL_PREPARING against team %d (%S) after %d turns with enemy power percent %d", getID(), GET_PLAYER(getLeaderID()).getCivilizationDescription(0), iI, GET_PLAYER(GET_TEAM((TeamTypes)iI).getLeaderID()).getCivilizationDescription(0), AI_getWarPlanStateCounter((TeamTypes)iI), iEnemyPowerPercent );
		}
		AI_setWarPlan(((TeamTypes)iI), NO_WARPLAN);
	}
}
dave has added an else block that uses the undefined variable:
Code:
//CD Tweaks - opportunistic convert to dogpile to take advantage of a powerful target being attacked by someone else
else if (bShareValid && iEnemyPowerPercent >= 140 && GET_TEAM((TeamTypes)iI).getAtWarCount(true) > 0)
I guess the easiest fix is to move this part
Spoiler :
Code:
bAreaValid = false;
bShareValid = false;
for(pLoopArea = GC.getMapINLINE().firstArea(&iLoop); pLoopArea != NULL; pLoopArea = GC.getMapINLINE().nextArea(&iLoop))
{
	if (AI_isPrimaryArea(pLoopArea))
	{
		if (GET_TEAM((TeamTypes)iI).countNumCitiesByArea(pLoopArea) > 0)
		{
			bShareValid = true;

			AreaAITypes eAreaAI = AI_calculateAreaAIType(pLoopArea, true);

			if ( eAreaAI == AREAAI_DEFENSIVE)
			{
				bAreaValid = false;
			}
			else if( eAreaAI == AREAAI_OFFENSIVE )
			{
				bAreaValid = true;
			}
		}
	}
}
above this line:
if (AI_getWarPlanStateCounter((TeamTypes)iI) > ((10 * iTimeModifier) / (bEnemyVictoryLevel4 ? 400 : 100)))
This bug is not going to cause a crash on its own, I also doubt that it'll hurt the AI much, but it can prevent other problems from being reproduced reliably (because the value of bShareValid will be unpredictable if it's not initialized) and can cause out-of-sync errors in multiplayer (resulting from different values of bShareValid on two players' PCs).
Still no connections to the getcompletedspaceshipproject from the dmp file?
No, still just code for AI war planning. I've just seen a dmp posted in the FfH forums. I'm curious what, if anything, lfgr will be able to learn from that.
 

Re-loader

Warlord
Joined
Feb 12, 2007
Messages
149
Could be a different cause maybe. But if you compile a debug DLL from the same source (i.e. with pNearestCity initialized), there is no crash?

And the crash with the release DLL is consistently reproducible while the debug DLL never crashes (on that particular turn)? That could be, or maybe it's just crashing randomly with both builds.

But that DLL had been crashing before, and you haven't changed anything about it? Or ... I guess we're talking about a different turn/ savegame now.

I thought dave's DLL, just with pTheirNearestCity=NULL (and re-compiled for the change to take effect) is what crashes. 🙃
And which team is that? Does it have cities? Assuming that each team has only one member, no player has been defeated and it's not a scenario, the positioning on the Foreign Advisor should correspond to the ID, i.e. the human civ in the first slot (ID 0), then increasing IDs from left to right. That's eTeam, I assume. May also need to knowto really figure out what's going on, i.e. why that latter team is apparently unable to locate cities of team 11 (not even when cheating with map knowledge).I guess that makes sense; the debugger doesn't keep track of the node returned by the headMissionQueueNode() function. Could insert a variable above the switch block
MissionTypes eTmp = headMissionQueueNode()->m_data.eMissionType;
then recompile, choose Debug when the assertion fails and then hover over eTmp (or find it in the Locals window). That would be just a temporary change to diagnose the problem. But I'd agree that it's not a priority.Sheesh, dave has introduced a lot of those errors. Also the one I came across in my brief debugging session:Though the convention of declaring all variables at the start of a function – surely already widely discouraged at the time – is really Firaxis's fault. So, bShareValid gets declared at the start of CvTeamAI::AI_doWar, but is only initialized and supposed to be used in this if block:
Spoiler :
Code:
if (AI_getWarPlanStateCounter((TeamTypes)iI) > ((10 * iTimeModifier) / (bEnemyVictoryLevel4 ? 400 : 100)))
{
    bAreaValid = false;
    bShareValid = false;

    for(pLoopArea = GC.getMapINLINE().firstArea(&iLoop); pLoopArea != NULL; pLoopArea = GC.getMapINLINE().nextArea(&iLoop))
    {
        if (AI_isPrimaryArea(pLoopArea))
        {
            if (GET_TEAM((TeamTypes)iI).countNumCitiesByArea(pLoopArea) > 0)
            {
                bShareValid = true;

                AreaAITypes eAreaAI = AI_calculateAreaAIType(pLoopArea, true);

                if ( eAreaAI == AREAAI_DEFENSIVE)
                {
                    bAreaValid = false;
                }
                else if( eAreaAI == AREAAI_OFFENSIVE )
                {
                    bAreaValid = true;
                }
            }
        }
    }

    if ( (bAreaValid && (iEnemyPowerPercent < 140)) || (!bShareValid && (iEnemyPowerPercent < 110)) || (GET_TEAM((TeamTypes)iI).AI_getLowestVictoryCountdown() >= 0) )
    {
        if( gTeamLogLevel >= 1 )
        {
            logBBAI("      Team %d (%S) switching WARPLANS against team %d (%S) from PREPARING_TOTAL to TOTAL after %d turns with enemy power percent %d", getID(), GET_PLAYER(getLeaderID()).getCivilizationDescription(0), iI, GET_PLAYER(GET_TEAM((TeamTypes)iI).getLeaderID()).getCivilizationDescription(0), AI_getWarPlanStateCounter((TeamTypes)iI), iEnemyPowerPercent );
        }
        AI_setWarPlan(((TeamTypes)iI), WARPLAN_TOTAL);
    }
    else if (AI_getWarPlanStateCounter((TeamTypes)iI) > ((20 * iAbandonTimeModifier) / 100))
    {
        if( gTeamLogLevel >= 1 )
        {
            logBBAI("      Team %d (%S) abandoning WARPLAN_TOTAL_PREPARING against team %d (%S) after %d turns with enemy power percent %d", getID(), GET_PLAYER(getLeaderID()).getCivilizationDescription(0), iI, GET_PLAYER(GET_TEAM((TeamTypes)iI).getLeaderID()).getCivilizationDescription(0), AI_getWarPlanStateCounter((TeamTypes)iI), iEnemyPowerPercent );
        }
        AI_setWarPlan(((TeamTypes)iI), NO_WARPLAN);
    }
}
dave has added an else block that uses the undefined variable:
Code:
//CD Tweaks - opportunistic convert to dogpile to take advantage of a powerful target being attacked by someone else
else if (bShareValid && iEnemyPowerPercent >= 140 && GET_TEAM((TeamTypes)iI).getAtWarCount(true) > 0)
I guess the easiest fix is to move this part
Spoiler :
Code:
bAreaValid = false;
bShareValid = false;
for(pLoopArea = GC.getMapINLINE().firstArea(&iLoop); pLoopArea != NULL; pLoopArea = GC.getMapINLINE().nextArea(&iLoop))
{
    if (AI_isPrimaryArea(pLoopArea))
    {
        if (GET_TEAM((TeamTypes)iI).countNumCitiesByArea(pLoopArea) > 0)
        {
            bShareValid = true;

            AreaAITypes eAreaAI = AI_calculateAreaAIType(pLoopArea, true);

            if ( eAreaAI == AREAAI_DEFENSIVE)
            {
                bAreaValid = false;
            }
            else if( eAreaAI == AREAAI_OFFENSIVE )
            {
                bAreaValid = true;
            }
        }
    }
}
above this line:
if (AI_getWarPlanStateCounter((TeamTypes)iI) > ((10 * iTimeModifier) / (bEnemyVictoryLevel4 ? 400 : 100)))
This bug is not going to cause a crash on its own, I also doubt that it'll hurt the AI much, but it can prevent other problems from being reproduced reliably (because the value of bShareValid will be unpredictable if it's not initialized) and can cause out-of-sync errors in multiplayer (resulting from different values of bShareValid on two players' PCs).No, still just code for AI war planning. I've just seen a dmp posted in the FfH forums. I'm curious what, if anything, lfgr will be able to learn from that.
I had a 2nd attempt at a Release dll and the crash has not occurred. So I must have done something wrong. Probably because the release dll was not in the correct place, I found it and put it in the right place. No crashes as yet. Previously, with debugger attached it was not crashing, but I'm more confident, and a little bit more competent with all this now.

So teamid does not correspond to the team number in wbs file?

I will make those adjustments and compile another release dll.
 
Top Bottom