<URL: http://bugs.freeciv.org/Ticket/Display.html?id=39627 >

On 28/08/07, Marko Lindqvist <[EMAIL PROTECTED]> wrote:
>  This happened with S2_1 when trying to reproduce another bug.
>  1) Started client and loaded saved game (launching server internally)
>  2) Selected player and started game
>  3) After a while I decided that I need certain kind of player
> interaction for my test
>  4) Started another client and connected to running game
>  5) Selected one of the AI players and 'Take this player' from right-mouse 
> menu.

 Server sent all the rulesets (specifically: packet_ruleset_control)
for connection doing /take in running game. This caused client to
free, and then to allocate again, memory for ruleset data,
invalidating pointers. In this particular crash newly allocated
nations array was in different memory segment than where old one used
to be, meaning that all player->nation pointers were pointing to some
other data.

 Patch attached. I'm not aware of any problems caused by not sending
ruleset data when /take command is issued, but it doesn't mean there
is none... (Remember that in order to /take client already has to be
connected to current game and it has received identical rulesets)

 - ML

diff -Nurd -X.diff_ignore freeciv/server/stdinhand.c freeciv/server/stdinhand.c
--- freeciv/server/stdinhand.c	2007-08-25 15:15:55.000000000 +0300
+++ freeciv/server/stdinhand.c	2007-08-29 00:37:36.000000000 +0300
@@ -2946,8 +2946,9 @@
   /* if we want to switch players, reset the client if the game is running */
   if (server_state == RUN_GAME_STATE) {
     send_game_state(pconn->self, CLIENT_PRE_GAME_STATE);
-    send_rulesets(pconn->self);
-    send_server_settings(pconn->self);
+    /* We don't send rulesets here. Client already has nations
+     * assigned to players and resetting nations with
+     * ruleset_control packet is not a good idea. */
     send_player_info_c(NULL, pconn->self);
     send_conn_info(game.est_connections,  pconn->self);
Freeciv-dev mailing list

Reply via email to