[Freeciv-Dev] Re: CMA crash when choosing new govt (PR#1546)

[Kenn Munro <kenn@xxxxxxxxxxxxxx>]

I applied your patch to June 27 CVS.  It fixes the problems caused by
government and tax change between turns.  It gives a message like "CMA:
Jalapa has changed and the calculated result can't be applied. Will
retry.", and it keeps working.

However, one time, while repeatedly pressing shift-t, clicking, and
pressing enter to change the tax rate between turns, the client spat out
many of these messages:
Gtk-CRITICAL **: file gtktogglebutton.c: line 510
(gtk_toggle_button_clicked): assertion `GTK_IS_TOGGLE_BUTTON (button)'
failed.
And then quit with a segmentation fault.  I have no idea what triggered
it and haven't been able to reproduce it.

The only other error I found happened while disbanding units.. I will
submit it as a separate bug.

Kenn


On Thu, 2002-06-27 at 06:45, Raimar Falke wrote:
> On Thu, Jun 27, 2002 at 12:30:21AM -0700, Per I Mathisen wrote:
> > On 26 Jun 2002, Kenn Munro wrote:
> > > The patch fixes the bug.. it is no longer possible to change government
> > > while the client is still busy doing the start-of-turn stuff.
> > >
> > > But, you were correct in assuming that "other changes (tax rates for
> > > example) may have such problems".
> > ...
> > > Probably not a *big* deal.. you can't end-turn when the tax dialog is
> > > up, so the user would have to end-turn, then quickly Shift-T and change
> > > the rate.
> > 
> > But even if you can't end turn, the turn can still end while you have that
> > dialog up (due to timeout).
> > 
> > > I also got the same error for another city while disbandings units from
> > > a city dialog box while between turns.  I suspect there may be many more
> > > ways to cause such problems.  As they won't all be found/fixed before
> > > release, there should be a mention in BUGS of bad things happening
> > > sometimes when doing stuff while the client is between turns.
> > >
> > > And, what's the best way to fix them all?  Address them each as they are
> > > found or not allow any user intervention until all turn stuff is
> > > complete?
> > 
> > Why does this happen? I don't see any good reason why you shouldn't be
> > able to change government while agents are processed, as the agent event
> > is scheduled. Isn't there an underlying design flaw here?
> 
> First I want to thank Kenn for the testing.
> 
> Second I want to thank Per for accusing the architecture. This is
> always a good way to get someone moving.
> 
> It turns out that the previous fix is just a band-aid (lazy me). And
> the real fix is a one liner (call of clear_caches).
> 
> For the protocol here is the situation (enlarge your xterm a bit)
> (this is a bit like
> what-you-never-wanted-to-know-about-agents-and-network-interaction
> (and also the reason why server side AI is a lot easier)):
> 
>    CLIENT                                        SERVER
>   revolution
>                                        (activities which doesn't matter here)
>   send turn done
>                                        end turn activities
>                                          update the player info
>   new player info
>   popup government dialog
>   user choose democracy
>                                          [ still in the end turn activities]
>                                          refreshing all cities and sending 
> them to the client
>   new city info for city X
>     CMA calculated with government ANARCHY
>     CMA have to change the city X
>     CMA send requests
>                                       finish end turn activities
>                                       Democracy request:
>                                         government set to Democracy
>                                         send player info
>                                         refreshing all cities and sending 
> them to the client
>                                       CMA request for city X
>                                         send new city_info for X USING 
> DEMOCRACY
>       new player info with Democracy
>       city_infos:
>         cities are updated
>         cities are queue for the agents
>     city_info for X which doesn't 
>      match the calculated one. Previously 
>      this gone BOOM. Now it clears the 
>      cache and recalculates city X 
>      with Democracy.
>     CMA calculated with government Democracy
>     CMA have to change the city X
>     CMA send requests
>                                       CMA request for city X
>                                         send new city_info for X using 
> Democracy
>     city_info for X which match
>   CMA action for city X finished
>   agents.c will search for other 
>    queued cities which have changed and
>    need verification that there are still 
>    optimal
>       o
>       o
>       o
> 
> So Kenn can you please test this against the rate changes "attack"?
> 
>       Raimar
>