Tested S2_3 before and after this patch with an autogame.

Good news: the autogame with the patch ran to completion without anything obviously bad happening.

Bad news: this seems to have perturbed the outcome of autogames. In fact it's different from the very start: the order in which start positions are assigned to players is different (although the nations/leaders are the same).
The change seems to be deterministic, at least: two autogames without the patch gave similar-looking results up to the point I stopped them, and the same with the patch.
This doesn't actually break anything, but it's worrying, as I don't think this patch should have perturbed anything like this -- even the extensive change to assign_continent_flood() shouldn't have changed the continent numbers, I think.

Changes to avoid stack overflow with large maps:
- many instances of allocation of map-sized arrays on the stack have been
replaced with heap allocation
- assign_continent_flood() no longer uses recursion

Patch by akfaew@gna and Matthias Pfafferodt (syntron@gna) with a few tweaks
by me (originally part of a patch in gna bug #18087).

See gna bug #17962.

(Browse SVN revision 19941)

I intend to apply file #13531 (from bug #18087) to try to deal with this before 2.3.0-RC1 is released.

Since there isn't much time before RC1, pre-commit testing would be appreciated (especially by Windows users).

Map creation problem reproduced in Win7 using only server (trying to launch autogame).

I even got some kind of backtrace: segfault in map_pos_to_index(). Before that backtrace is filled with assign_continent_flood() - and by filled I mean that I stopped listing them after 15000.

So it seems like unlimited recursion in assign_continent_flood() eventually causing stack overflow.

...or network (connection between server and client) buffers overflowing with such a massive amount of data. That could happen if for some reason server is sending data faster than client accepts. Server should be as fast in Windows as in Linux, but Windows gtk is definitely slower.

could you test, if the server of the windows build prints some usefull output before it exits (i.e. start the sever seperate)

I did load the four scenarios without problem with S2_3 on an Ubuntu 10.10 32bit.

It must be a problem with windows binaries...

Another data point:

User GM1350 on the forum, who's put together a number of large map scenarios, reports in email that they cannot load some of them in the Windows version of 2.3.0-beta3, but they can load others (see thread). I think the examples mentioned were:

• europe-332x264-v1.8.sav.gz
• middleeast-400x300-v1.1.sav.gz
• earth-500x250-v1.0.sav.gz
• italy-420x300-v1.0.sav.gz

GM1350 writes: "If I use my maps (ex. Earth) and I select this map in ''Scenario Game'' (on Windows Vista).. I see this:
Starting server... Welcome to the Freeciv version 2.3.0-beta3 (beta version) Server at port 5556. You are logged in as 'Administrator' connected to Administrator. Established control over the server. You have command access level 'hack'. Administrator: 'set topology "WRAPX|ISO"' Option: topology has been set to "Wrap East-West" and "Isometric" (WRAPX|ISO). Lost connection to server (read error)! "But freeciv-server.rpt is white!"

Which seems to indicate that the server has crashed.

I haven't tried to work out in detail what's different between the reported working and non-working ones. The non-working ones tend to have a larger number of tiles, but there isn't a simple threshold in number of tiles that says whether or not it'll work.

However, I have no trouble loading any of these scenarios on Ubuntu Linux 10.04.2 on x86_64 (64-bit), either in a client-spawned server or in a standalone server (and I don't see any errors or warnings in the latter), either with 2.3.0-beta3 or the head of S2_3.

Similarly, I have no trouble generating maps where size=90.

So it looks like we're dealing with a Windows-specific server crash, which is a shame as I don't really know how to get good post-mortem diagnostics for Windows.

I guess it's also possible that it's an issue when Freeciv is compiled for 32-bit architectures -- some quantity that needs to be 64-bit is not? Can someone confirm whether the above scenarios work when compiled for some 32-bit Unix platform?

Possibly running valgrind on Linux will show something up; I haven't tried it yet.

I have tried it many times with two different PCs, first running on Windows 7 and the second one on Windows XP SP3 and many different settings but with no success

Program is not able to generate maps of size above 70-80 thousand tiles (exact number is a bit varying). After chosing "Start" it just returns to the main screen with error message "Lost connection to server (read error)!"