Infinite loop bug after 1st turn

[instafluff0]

I'm not sure if you saw, but I initially stumbled onto this in the animations branch (#36 (comment)), where, somewhat unpredictably, after the 1st turn but before the 2nd begins, the game appears to get in an infinite loop, with rising memory usage. I'm able to somewhat consistently have this happen if I continually restart a new game and move to the 2nd turn, going back to the main menu and trying again. Usually by the 4th or 5th restart it happens.

I was puzzled by this and assumed it was something obscure in the animations code. It looks like get_unit_ptr is among the functions called over and over, but pinning down the exact functions beyond that is hard.

Anyway, I found it again today in the seasonal cycle branch. First, I noticed in my in-progress (mostly Codex at this point) branch that removes the cache and pulls only the day-night+season art for a given hour (https://github.com/instafluff0/C3X_Districts/tree/seasonal-cycle-no-cache).

I thought that was strange though, and next tried the existing r28-seasonal-cycle branch:

OK..... how about the same branch, but with day-night & seasons disabled?

Hmmmm. How about my master branch, which is fully synced and aligned with yours?

Yikes. And just to rule it out, how about no day-night cycle, no districts? (and no seasonal cycle, no animations, as those aren't merged yet)

So, as far as I can tell, we have a bug somewhere in the code right now that can force the game to go into an infinite loop and use an increasing amount of memory. Based on my configs I don't think it's district/day-night related, but it's really hard to say.

Anyway here is the custom.c3x_config.ini I'm using as of my last test above (I don't know if scenarios have this issue as well but assume so)

minimum_city_separation = 8
city_work_radius = 6
auto_zoom_city_screen_for_large_work_areas = false
show_ai_city_location_desirability_if_settler = true

ai_worker_requirement_percent = 400

;seasonal_cycle_mode = specified
;enabled_seasons = [ summer fall winter spring ]
;pinned_season_for_seasonal_cycle = winter
;elapsed_minutes_per_season_transition = 3
;fixed_turns_per_season = 3
;transition_season_on_day_night_hour = 0
;
;day_night_cycle_mode = every-turn
;elapsed_minutes_per_day_night_hour_transition = 3
;fixed_hours_per_turn_for_day_night_cycle = 1
;pinned_hour_for_day_night_cycle = 0

enable_natural_wonders = true
add_natural_wonders_to_scenarios_if_none = true
show_natural_wonder_name_on_map = true
minimum_natural_wonder_separation = 10

enable_custom_animations = true

enable_districts = false
enable_neighborhood_districts = true
enable_wonder_districts = true
enable_distribution_hub_districts = true
enable_aerodrome_districts = true
enable_port_districts = true
enable_bridge_districts = true
enable_canal_districts = true
enable_central_rail_hub_districts = true
enable_energy_grid_districts = true
enable_great_wall_districts = true

cities_with_mutual_district_receive_buildings = true
cities_with_mutual_district_receive_wonders = true
show_message_when_building_received_by_mutual_district = true
show_message_when_building_lost_to_destroyed_district = true

air_units_use_aerodrome_districts_not_cities = true
naval_units_use_port_districts_not_cities = true

maximum_pop_before_neighborhood_needed = 6
per_neighborhood_pop_growth_enabled = 3
neighborhood_needed_message_frequency = 4
destroying_neighborhood_reduces_pop = true

completed_wonder_districts_can_be_destroyed = true
destroyed_wonders_can_be_built_again = true

distribution_hub_yield_division_mode = scale-by-city-count
ai_distribution_hub_build_strategy = auto
distribution_hub_food_yield_divisor = 2
distribution_hub_shield_yield_divisor = 2
ai_ideal_distribution_hub_count_per_100_cities = 50
max_distribution_hub_count_per_100_cities = 50

central_rail_hub_distribution_food_bonus_percent = 25
central_rail_hub_distribution_shield_bonus_percent = 25

expand_water_tile_checks_to_city_work_area = true
workers_can_enter_coast = true
max_contiguous_bridge_districts = 3
max_contiguous_canal_districts = 5
ai_canal_eval_min_bisected_land_tiles = 20
ai_bridge_canal_eval_block_size = 10
ai_bridge_eval_lake_tile_threshold = 5
ai_can_replace_existing_districts_with_canals = true
ai_builds_bridges = true
ai_builds_canals = true

disable_great_wall_city_defense_bonus = true
great_wall_districts_impassable_by_others = true
auto_build_great_wall_around_territory = true
great_wall_auto_build_wonder_name = "The Great Wall"
ai_auto_build_great_wall_strategy = all-borders

I also tested by completely removing my custom C3X config and still was able to reproduce it, so default settings can also lead to it, it seems.

Are you able to reproduce this? (hopefully I'm not crazy)

[instafluff0]

Update: as an experiment, I tried doing fresh installs of past releases, using just default configs. I haven't tried farther back than R24, but can confirm that this is an issue at least as far back as that, and with all of them.

Maybe it's a bug that's been in Civ 3 forever? Hard to say.

Given this, I'm going to assume this is not an issue with my current PRs and due to something else. I also can't rule out this being due to my environment or VM, but that would be kind of surprising.

[maxpetul]

Unfortunately I can't replicate this. I tried installing the mod off the r28-animations branch, using your custom config, and doing what you showed in that last GIF, but after 10 or maybe 15 tries, it never froze. Not sure what to make of this. You're on Windows 11, right? I'm on 10, so that might be it. How did you determine that the game was calling get_unit_ptr? Can you get a more complete stack trace?

[instafluff0]

Huh! That's actually quite a relief! If it's only me - or potentially others but they haven't run into it or reported yet - that's good. Yes, Windows 11 on a Parallels VM.

How did you determine that the game was calling get_unit_ptr?

I put the recompiled code in a Ghidra and grabbed the address from the Visual Studio debugger. I pasted the resulting function in Codex and asked it to look in injected_code.c to see if the pattern looked familiar. Codex suggested get_unit_ptr, so I added some logging and sure enough it was right.

Can you get a more complete stack trace?

Sure, though let's treat this as a backburner bug for now. I can take a look again after we get through the PRs, if that's alright with you.