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

map.num_continents is never actually sent to the client - the client
just deduces it from the continent numbers of each tile.  So when new
terrain is revealed, which can happen mid-turn, the num_continents can
rise (packhand.c:2039 in S2_0).  This is the same way things are handled
in trunk as well so it's likely this issue is still present.

>From the backtrace on the valgrind error (--db-attach=yes):

(gdb) p pcity->tile->continent
$11 = 53
(gdb) p map.num_continents
$12 = 5

For a quick fix the attached patch will probably do (possibly for
S2_1/S2_2/trunk as well; it should certainly be harmless there).

Similar problems may easily crop up elsewhere however.  The question
here is how a tile with continent 53 gets into the system (at the client
end) while map.num_continents is still set at 5.  A closer look at the
backtrace will probably show the num_continents gets properly changed
later on in the same packet-handling sequence that causes the crash. 
I'd think the easiest and best fix by far would be to have
num_continents just sent to the client outright.  I don't know why it's
done as it is; any idea of fairness (as sending num_continents to the
client gives away global information) is misplaced as some players will
have higher continent numbers than others and will therefore gain more
global information by it - meaning the current system is unfair.


Index: common/improvement.c
--- common/improvement.c	(revision 14840)
+++ common/improvement.c	(working copy)
@@ -285,7 +285,7 @@
   if (pplayer) {
     equiv_list[IR_PLAYER] = pplayer->improvements;
-    if (cont > 0 && pplayer->island_improv) {
+    if (cont > 0 && cont <= map.num_continents && pplayer->island_improv) {
       equiv_list[IR_ISLAND] =
                           &pplayer->island_improv[cont * game.num_impr_types];
Freeciv-dev mailing list

Reply via email to