bugFreeciv - Bugs: bug #17816, 1: City size 4, citizen count 5...

 
 
Show feedback again

bug #17816: 1: City size 4, citizen count 5 for Nassau

Submitted by:  Marko Lindqvist <cazfi>
Submitted on:  Mon Feb 28 05:17:27 2011  
 
Category: generalSeverity: 3 - Normal
Priority: 5 - NormalStatus: Duplicate
Assigned to: Marko Lindqvist <cazfi>Open/Closed: Closed
Release: TRUNK r19430Operating System: None
Planned Release: Contains string changes: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sat Jan 23 09:55:16 2016, comment #11:

Bug #24194 should have fixed this, judging by comment 5 in that ticket?

Jacob Nevins <jtn>
Project Administrator
Wed Jul 16 08:10:41 2014, comment #10:

Did this go away?

Bug #20745 suggests not (that bug's specifically about concurrent movement, which I assume is in use here).

Comment #5 has an explanation for this. Is it still valid?

Bug #22350 comment 2 (misplaced) suggests it's still happening with 2.5.0-beta0 (and circumstance is "When an enemy city has more than 1 nationality and is captured", which sounds plausibly like comment #5).

Jacob Nevins <jtn>
Project Administrator
Sat Oct 6 19:06:44 2012, comment #9:

r21878 of S2_4

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Sat Oct 6 19:04:45 2012, comment #8:

Again reproducible in r21878. Backtrace seems similar to what I explained in comment #5. Turn 520.

(file #16652)

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Fri Mar 30 00:34:43 2012, comment #7:

Not going to make 2.3.2 either. Removing release target, but it would be good to get to the bottom of it.

Jacob Nevins <jtn>
Project Administrator
Fri Nov 18 21:37:14 2011, comment #6:

Clearly not going to make 2.3.1. But it looks like we have a lead and just need tuits, so I'll keep a 2.3.x target.

Jacob Nevins <jtn>
Project Administrator
Tue Jun 7 12:12:50 2011, comment #5:

Ok, it's related to that map_clear_borders().

When city shrinks (due to enemy attack in this case) border is temporarily removed from tile that neighboring city is working on. In map_claim_ownership_full() workers of that city are frozen with city_map_update_tile_frozen() and there's no thaw for that city before all the cities are sent with sync_cities()

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Tue Jun 7 12:02:16 2011, comment #4:

Turns out to be rather complicated one to track down.

Anyway, there's suspicious code in city_reduce_size() that might be related (or bug of its own):

map_clear_border(pcity->tile);
city_size_add(pcity, -pop_loss);
map_claim_border(pcity->tile, pcity->owner);

If I'm right:
map_clear_border() can cause all the workers of the city to leave fields! They are returned to some fields with auto_arrange_workers() later, but all the worker arrangements player has done are lost.

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Tue Jun 7 11:12:10 2011, comment #3:

Findings so far:

- City size has not recently changed, so problem is in increasing citizen count when city does not grow.
- Last time information of city was sent without problems, it had just 4 workers
- City has 4 workers and one elvis. Note that elvis is DEFAULT_SPECIALIST that gets added in many places in code when city size is assumed to grow or worker is taken off the field.
- City radius has not changed, so problem cannot be in how workers from that way lost territory are turned to elvises

  • City is in worker update queue: it may has just turned worker to elvis, but feelings calculation sanity has not yet been restored (in queue thaw)

This last point means it should be quite straightforward to check where the freeze begins and why there is no thaw once I get backtrace.

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Tue May 31 20:13:40 2011, comment #2:

See also bug #17392.

Jacob Nevins <jtn>
Project Administrator
Mon Feb 28 17:08:10 2011, comment #1:

- Attached autogame produces this error message somewhere between turns 250 and 275 (between those autosaves)

(file #12600)

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Mon Feb 28 05:17:27 2011, original submission:

Seen in autogame. Current TRUNK, default ruleset. Once this run ends and I get results gathered, I'll test if it is reproducible.

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #16652:  regression.serv added by cazfi (299B - application/octet-stream)
file #12600:  regression.serv added by cazfi (299B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jtn (Posted a comment)
  • -unavailable- added by cazfi (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Error: not logged in

     

     

    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat Jan 23 15:06:45 2016cazfiCategoryNone=>general
      StatusNone=>Duplicate
      Assigned toNone=>cazfi
      Open/ClosedOpen=>Closed
    Sat Oct 6 19:04:45 2012cazfiAttached File-=>Added regression.serv, #16652
    Fri Mar 30 00:34:43 2012jtnPlanned Release2.3.2, 2.4.0=>
    Fri Nov 18 21:37:14 2011jtnPlanned Release2.3.1, 2.4.0=>2.3.2, 2.4.0
    Thu Jun 9 21:15:14 2011cazfiPlanned Release=>2.3.1, 2.4.0
    Mon Feb 28 17:08:10 2011cazfiAttached File-=>Added regression.serv, #12600
      Release=>TRUNK r19430
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup