<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.
-jason
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
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
