Single Player bugs and crashes v39 plus (SVN) - After the 20th of July 2019

@alberts2 your last commit introduced this python error when loading save - can you guys test game?
Code:
Traceback (most recent call last):
  File "BugEventManager", line 308, in _handleDefaultEvent
  File "CvEventManager", line 621, in onLoadGame
  File "CvEventManager", line 484, in gameStart
  File "CvAdvisorUtils", line 70, in resetNoLiberateCities
AttributeError: 'CvUnitInfo' object has no attribute 'getHasBuilding'
 
@alberts2 your last commit introduced this python error when loading save - can you guys test game?
Code:
Traceback (most recent call last):
  File "BugEventManager", line 308, in _handleDefaultEvent
  File "CvEventManager", line 621, in onLoadGame
  File "CvEventManager", line 484, in gameStart
  File "CvAdvisorUtils", line 70, in resetNoLiberateCities
AttributeError: 'CvUnitInfo' object has no attribute 'getHasBuilding'

Already fixed.
 
@Toffer90
I'm getting this error, when pressing alt+ctrl on units to select them all
Code:
Traceback (most recent call last):
  File "BugEventManager", line 321, in _handleConsumableEvent
  File "CvEventManager", line 330, in onMouseEvent
  File "CvEventManager", line 164, in beginEvent
  File "CvEventManager", line 2850, in __eventEditCityBegin
  File "CvWBPopups", line 71, in initEditCity
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 21: ordinal not in range(128)
 
Repeatable CTD at EoT 10824 & 10845: just hit end turn
@Thunderbrd

This crash happens here in CvUnitAI.cpp.
Code:
                if ( (eFlags & UNITVALUE_FLAGS_DEFENSIVE) != 0 )
                {
                    //    Terrain defense
                    for(int iJ = 0; iJ < GC.getNumTerrainInfos(); iJ++)
                    {
                        if ( kPromotion.getTerrainDefensePercent((TerrainTypes)iJ) != 0 ||
                             kPromotion.getIgnoreTerrainDamage() == iJ )
                        {
                            int iNumRevealedAreaTiles = area()->getNumRevealedTiles(getTeam());
                            int    iNumRevealedAreaThisTerrain = area()->getNumRevealedTerrainTiles(getTeam(), (TerrainTypes)iJ);

                            //    Note - used 1000 multiplier here for better granularity because there are
                            //    a lot of terrain types.  We multiply the actual ratio by 2 because in practise the AI will
                            //    deploy the units to appropriate terrains/features when it can so the the effective value is
                            //    higher than the raw proportion would apply
                            int    iTerrainWeight = (2*1000*iNumRevealedAreaThisTerrain)/iNumRevealedAreaTiles;
For some reason area()->getNumRevealedTiles(getTeam()) returns 0. This can't be 0 because if a unit is on a plot that plot should be revealed and area()->getNumRevealedTiles(getTeam()) should at least return 1.
 
Last edited:
I'm playing with Developing Leaders, No Positive Starting Traits and New Complex Traits.
After I got my first positive trait: Nomad, I got Great Hunter. I made it Great Tracker. He got his Hunter 1 (due to Hunting Instructions - finally! Thank you for this) and his Nomad 1 promotions (due to my leader's positive trait Nomad).
Then I've updated the game from 10853 to 10862. And then, after I got my second Great Tracker, he didn't get his Nomad 1 promotion.
Something got broken in promotion assessment.
 
@Toffer90
I'm getting this error, when pressing alt+ctrl on units to select them all
Code:
Traceback (most recent call last):
  File "BugEventManager", line 321, in _handleConsumableEvent
  File "CvEventManager", line 330, in onMouseEvent
  File "CvEventManager", line 164, in beginEvent
  File "CvEventManager", line 2850, in __eventEditCityBegin
  File "CvWBPopups", line 71, in initEditCity
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 21: ordinal not in range(128)
Fixed in 10863.
 
@Thunderbrd

This crash happens here in CvUnitAI.cpp.
Code:
                if ( (eFlags & UNITVALUE_FLAGS_DEFENSIVE) != 0 )
                {
                    //    Terrain defense
                    for(int iJ = 0; iJ < GC.getNumTerrainInfos(); iJ++)
                    {
                        if ( kPromotion.getTerrainDefensePercent((TerrainTypes)iJ) != 0 ||
                             kPromotion.getIgnoreTerrainDamage() == iJ )
                        {
                            int iNumRevealedAreaTiles = area()->getNumRevealedTiles(getTeam());
                            int    iNumRevealedAreaThisTerrain = area()->getNumRevealedTerrainTiles(getTeam(), (TerrainTypes)iJ);

                            //    Note - used 1000 multiplier here for better granularity because there are
                            //    a lot of terrain types.  We multiply the actual ratio by 2 because in practise the AI will
                            //    deploy the units to appropriate terrains/features when it can so the the effective value is
                            //    higher than the raw proportion would apply
                            int    iTerrainWeight = (2*1000*iNumRevealedAreaThisTerrain)/iNumRevealedAreaTiles;
For some reason area()->getNumRevealedTiles(getTeam()) returns 0. This can't be 0 because if a unit is on a plot that plot should be revealed and area()->getNumRevealedTiles(getTeam()) should at least return 1.
Could it happen if the unit is dead and in the temporary holding plot?

I can take a deeper look at it later.
 
I'm playing with Developing Leaders, No Positive Starting Traits and New Complex Traits.
After I got my first positive trait: Nomad, I got Great Hunter. I made it Great Tracker. He got his Hunter 1 (due to Hunting Instructions - finally! Thank you for this) and his Nomad 1 promotions (due to my leader's positive trait Nomad).
Then I've updated the game from 10853 to 10862. And then, after I got my second Great Tracker, he didn't get his Nomad 1 promotion.
Something got broken in promotion assessment.
Please give a save - will make it easier to find the issue.
 
CHOO CHOOs 10861 minidump from discord. Somehow source plot for a bombard mission is not valid. Unit is invalid somehow not sure.
upload_2019-8-2_20-13-42.png
 

Attachments

CHOO CHOOs 10861 minidump from discord. Somehow source plot for a bombard mission is not valid. Unit is invalid somehow not sure.
View attachment 531177
Can you look further back and see if you can verify the unit itself is valid at this point?

He says this is non replicable which is really really really weird.
For some reason area()->getNumRevealedTiles(getTeam()) returns 0. This can't be 0 because if a unit is on a plot that plot should be revealed and area()->getNumRevealedTiles(getTeam()) should at least return 1.
Along with this happening, I'm really wondering what dll change was made recently that would invite invalidation of plots or units somewhere.

I've seen this sort of thing happen when a loop is taking place and a unit dies while that loop is processing, but the loop doesn't know that and keeps going, calling on the now invalid unit. The sort of thing Alberts2 was talking about with invalidated pointers.
 
Here is save. But if I remember correctly this save was made after I've assigned Nomad 1 promotion to Great Tracker via World Builder. Please see Great Tracker in Yuracity (northern city).
Ok, that complicates it a little but it's something I should be able to investigate.
 
Can you look further back and see if you can verify the unit itself is valid at this point?
I don't really know what makes a unit valid, and being a minidump most information is not there. It is really just the function calls and their stacks. So I can't see the unit name or follow pointers or anything.

/edit I asked CHOO for a save so I can just run it a few turns until it crashes if it does.
 
I don't really know what makes a unit valid, and being a minidump most information is not there. It is really just the function calls and their stacks. So I can't see the unit name or follow pointers or anything.

/edit I asked CHOO for a save so I can just run it a few turns until it crashes if it does.
upload_2019-8-2_13-6-26.png

In this picture, you'll see I've looked back at the call stack where it would call for the unit that's actively under evaluation in those following CvUnit calls. Now, this being a minidump, information here can be completely inaccurate BUT all those ??? notes there as I hover over pUnitNode do suggest that while there's a unit expected at that node, there's no actual definition in that unit, which may well mean it died during the while loop that's taking place here. Possible that happened if the stack attacked a city that deals damage to incoming attackers. That or some outright bug somewhere that's wiping out units or their data during this loop.

That said, it made it past addMission and bombardRanged up to those points and I'd think it would've crashed there already so I'm probably way off.
 
Along with this happening, I'm really wondering what dll change was made recently that would invite invalidation of plots or units somewhere.

I've seen this sort of thing happen when a loop is taking place and a unit dies while that loop is processing, but the loop doesn't know that and keeps going, calling on the now invalid unit. The sort of thing Alberts2 was talking about with invalidated pointers.
I didn't notice anything like that.

The only thing that was off in that save is that the counting of revealed plots might not be working correctly. Maybe some unit action doesn't reveal plots correctly or this is caused by an error in the visibility calculation?
 
I didn't notice anything like that.

The only thing that was off in that save is that the counting of revealed plots might not be working correctly. Maybe some unit action doesn't reveal plots correctly or this is caused by an error in the visibility calculation?
If this isn't a small localized issue, then it's been a huge problem that should've led to numerous crashes before now. The only justification I can think of is if the unit is dead - because it's the area data that's tracking that amount of revealed tiles by player... something is definitely screwed up at a deeper level somewhere and it had to be recent or we'd have seen this long ago.

I will gladly look at his crash as soon as I can and investigate further of course.
 
Last edited:
If this isn't a small localized issue, then it's been a huge problem that should've led to numerous crashes before now. The only justification I can think of is if the unit is dead - because it's the area data that's tracking that amount of revealed tiles by player... something is definitely screwed up at a deeper level somewhere and it had to be recent or we'd have seen this long agol

Everything is possible i try to look at the save again tomorrow.

C2C has improved alot over the last years players reach much later eras now as they used to that could uncover some old bugs as well.
 
Everything is possible i try to look at the save again tomorrow.

C2C has improved alot over the last years players reach much later eras now as they used to that could uncover some old bugs as well.
True... I'm just thinking that if the area data isn't storing the revealed plots then we'd have seen a major problem in that before now. It might be possible that this is the only place in the code that it would cause a crash and that it's a rare spot to hit, but I doubt it.
 
Back
Top Bottom