Observed oddity in log from obj_t, possibly related to desync?

[Matthew]

This is not a reproducible bug report, but an oddity that might lead to one.

I got desynced from B-B after a few hours' play. I noticed the following in the log file just before the desync:



Afterwards, I looked at (512,1650) and found this:



The bridge on the west side of (512,1650) is possibly on a bus route. I don't think there will have any other player activity around those tiles. The only other player activity I can think of above those tiles would be a plane?

The tiles ending in 695x do not exist - they are off the map.

So I looked at the tiles you find if you swap the X and Y co-ordinates from those log warning lines:



That sequence of tiles could only occur from an aircraft, I think.

These tiles are on the approach to a runway:



Maybe this is something to do with the desync, or maybe it was just some coincidental graphical glitch. But I thought I'd post it in case someone else can recognize it as important (or not).

This occurred on a self-compiled build.

[ceeac]

This issue is also present in Standard: When running the big 12301 pak128 save from here with -debug 2, the log contains these lines:

Code Select Expand

Warning: karte_t::load():    loaded savegame from 0/2364, next month=1170210816, ticks=1169208280 (per month=1<<20)
Warning: convoi_t::go_alte_richtung():    convoy with wrong vehicle directions (id 15117) found => fixing!
ERROR: vehicle_base_t::leave_tile():    Fussgaenger 0x555b6ae790d8 could not be removed from (1680,2375,4)
For help with this error or to file a bug report please see the Simutrans forum:
https://forum.simutrans.com
ERROR: vehicle_base_t::leave_tile():    Fussgaenger 0x555b6ae793d8 could not be removed from (1680,2375,4)
For help with this error or to file a bug report please see the Simutrans forum:
https://forum.simutrans.com
Warning: obj_t::~obj_t():    Could not remove 0x555b59424508 from (261,830,0)
ERROR: vehicle_base_t::leave_tile():    Ding 0x555b7b4c4740 could not be removed from (2972,2474,7)
For help with this error or to file a bug report please see the Simutrans forum:
https://forum.simutrans.com
Warning: obj_t::~obj_t():    Could not remove 0x555b4dca1538 from (1679,2375,4)
ERROR: vehicle_base_t::leave_tile():    Fussgaenger 0x555b4dca1b38 could not be removed from (1679,2375,4)
For help with this error or to file a bug report please see the Simutrans forum:
https://forum.simutrans.com
ERROR: vehicle_base_t::leave_tile():    Fussgaenger 0x555b50bc1e98 could not be removed from (1679,2375,4)
For help with this error or to file a bug report please see the Simutrans forum:
https://forum.simutrans.com
Warning: obj_t::~obj_t():    Could not remove 0x555b72cde0c8 from (2417,1326,1)
Warning: obj_t::~obj_t():    Could not remove 0x555b72ce8668 from (178,2046,4)
Warning: obj_t::~obj_t():    Could not remove 0x555b50f6cff8 from (3091,10,1)
Warning: obj_t::~obj_t():    Could not remove 0x555b72ce7e28 from (2959,2494,4)
Warning: obj_t::~obj_t():    Could not remove 0x555b882d9868 from (1352,2889,0)
ERROR: vehicle_base_t::leave_tile():    Fussgaenger 0x555b87f73fb8 could not be removed from (2545,2253,8)
For help with this error or to file a bug report please see the Simutrans forum:
https://forum.simutrans.com

However, in my limited testing this only happened in single player.

[jamespetts]

Interesting - but difficult to decipher if it is in code common with Standard (and this code is not code that I have ever looked into). If this error occurs simultaneously on all clients and the server, it should not be responsible for a loss of synchronisation unless the fail state engages undefined behaviour or ends up engaging some code that is not network safe - but it is very difficult for me to evaluate that without knowing more about the object code in the first instance.

[ceeac]

After some more investigation I managed to find and fix the issue for Standard: This was related to pedestrian generation, for example this scenario could happen:

• There are 250 pedestrians on a single ground
• The first vehicle of a convoi enters the ground
• Up to 4 pedestrians are generated, causing the ground to be full
• The second vehicle fails to enter the ground
• When the convoi leaves the tile, the second vehicle fails be un-registered from the ground (because it was never registered in the first place)

So, to summarize, this is/was a bug, but not one that results in a desync. Check r10640/r10641.

[jamespetts]

After some more investigation I managed to find and fix the issue for Standard: This was related to pedestrian generation, for example this scenario could happen:

• There are 250 pedestrians on a single ground
• The first vehicle of a convoi enters the ground
• Up to 4 pedestrians are generated, causing the ground to be full
• The second vehicle fails to enter the ground
• When the convoi leaves the tile, the second vehicle fails be un-registered from the ground (because it was never registered in the first place)

So, to summarize, this is/was a bug, but not one that results in a desync. Check r10640/r10641.

Excellent, thank you for investigating this.

[prissi]

It is even more likely that more pedestrians are walking on that tile. So one should also change 254 in pedestrians_t::hop_check also to 240.

[Matthew]

So, to summarize, this is/was a bug, but not one that results in a desync. Check r10640/r10641.

Thank you for investigating this issue and fixing it, ceeac. You have removed one bug and made it easier to diagnose other issues too.