Follow-up Comment #3, bug #20940 (project freeciv):
Now I know how to do a guesswork decode of Windows stack traces, here's one:
0056C0A6 ___chkstk? or __alloca?
685EDE61 C:\MyGames\Freeciv\libglib-2.0-0.dll:685EDE61 g_main_loop_run
00E94A80 C:\MyGames\Freeciv\libgtk-win32-2.0-0.dll:00E94A80 gtk_main
77E6F1EB C:\WINDOWS\system32\kernel32.dll:77E6F1EB ProcessIdToSessionId
It's a bit of a leap from input_from_server() to call_handle_methods() in
agents.c, but not completely implausible -- the agents do respond to packets
coming from the network, and there's plenty of scope for call_handle_methods()
at least to be tail called (don't know about its callers).
Looking at assembler for 471779, I think we just called genlist_sort(). That
allocates a temporary array of the size of its list on the stack, so certainly
has capacity to blow the stack if passed a huge list (or invalid, although
NULL should be trapped).
Given that this is a huge game, I'm going to guess that the list is huge
rather than an invalid pointer -- it seems plausible that a large number of
unit movements could cause a large number of calls to agents (CMA?) to be
queued, especially if the client isn't keeping up with the server due to
spending all its time on animation. And Windows' stack limit is usually
smaller than Unix.
The obvious quick fix would be to malloc in genlist_sort(), but there are
* Doing a full list sort every time we look for the highest priority thing to
dequeue is pretty gross, when we could just keep the list sorted by inserting
the call at the right place in enqueue_call(), especially as that already does
a linear search over the list to look for duplicates.
* Maybe we also need some way to stop the agents queue growing huge in this
situation, if that's what's happening?
Reply to this item at:
Message sent via/by Gna!
Freeciv-dev mailing list