URL: http://bugs.freeciv.org/Ticket/Display.html?id=40113
Problem:
The client updates its client.playing global variable
from the player_idx field of packet_game_info (client/
packhand.c +1615) which is sent by the server via calls
to send_game_info. On connection (in the server function
establish_new_connection) the game info packet is sent
to the client before the client's connection is attached
to a player (thus the client sets its client.playing to
NULL). In the case where the client's player is then
created (attach_connection_to_player(pconn, NULL) returns
TRUE, server/connecthand.c +137) the server does not
notify the client that its game.info.player_idx has
changed (hence the client keeps its client.playing equal
to NULL even though it should now have a player, and
indeed receives conn and player info packets to that
effect). The client thus enters an inconsistent state
in which user actions result in undefined behaviour
and other oddities not expected by the programmers
(e.g. the originally reported assertion failure and
the insensitivity of the start button).
Solution:
The server sends another game info packet after the
client's player has been created. This ensures that
the client receives an updated player_idx field and
accordingly sets its client.playing to a valid pointer.
Discussion:
The initial call to send_game_info (server/connecthand.c
+134) cannot be removed because it initializes the client's
team-related data structures (among other things), which
are assumed to be initialized by the client's handlers of
player and conn info packets.
A cute consequence of the cause is that the client can
force the server to send it a valid player_idx, e.g.
by sending the command /set aifill 0 (or any command
that as a side-effect calls send_game_info in the
server). Hence when running a forked server (started
by the client using Start New Game), which sends
hardcoded commands right upon connection (i.e. /set
aifill 5), the client.playing variable in the client
is made consistent (i.e. not NULL) before the user can
notice any discrepancies.
It is strongly recommended that the game.info.player_idx
field be completely removed as soon as convenient, and the
client rely on a better designed and more logical mecha-
nism to update its client.playing global variable (the
conn info packet handler comes to mind).
From 0f1b111764fa53026c85cbb49d9f452e64019638 Mon Sep 17 00:00:00 2001
From: Madeline Book [EMAIL PROTECTED]
Date: Tue, 26 Feb 2008 23:42:37 -0500
Subject: [PATCH] (PR#40113) Fix assertion failure due to missing send_game_info.
Problem:
The client updates its client.playing global variable
from the player_idx field of packet_game_info (client/
packhand.c +1615) which is sent by the server via calls
to send_game_info. On connection (in the server function
establish_new_connection) the game info packet is sent
to the client before the client's connection is attached
to a player (thus the client sets its client.playing to
NULL). In the case where the client's player is then
created (attach_connection_to_player(pconn, NULL) returns
TRUE, server/connecthand.c +137) the server does not
notify the client that its game.info.player_idx has
changed (hence the client keeps its client.playing equal
to NULL even though it should now have a player, and
indeed receives conn and player info packets to that
effect). The client thus enters an inconsistent state
in which user actions result in undefined behaviour
and other oddities not expected by the programmers
(e.g. the originally reported assertion failure and
the insensitivity of the start button).
Solution:
The server sends another game info packet after the
client's player has been created. This ensures that
the client receives an updated player_idx field and
accordingly sets its client.playing to a valid pointer.
Discussion:
The initial call to send_game_info (server/connecthand.c
+134) cannot be removed because it initializes the client's
team-related data structures (among other things), which
are assumed to be initialized by the client's handlers of
player and conn info packets.
A cute consequence of the cause is that the client can
force the server to send it a valid player_idx, e.g.
by sending the command /set aifill 0 (or any command
that as a side-effect calls send_game_info in the
server). Hence when running a forked server (started
by the client using Start New Game), which sends
hardcoded commands right upon connection (i.e. /set
aifill 5), the client.playing variable in the client
is made consistent (i.e. not NULL) before the user can
notice any discrepancies.
It is strongly recommended that the game.info.player_idx
field be completely removed as soon as convenient, and the
client rely on a better designed and more logical mecha-
nism to update its client.playing global variable (the
conn info packet handler comes to mind).
---
server/connecthand.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git
