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?
00471779 _remove_and_return_a_call
004717EE _call_handle_methods
0042D92E _input_from_server
6C3463D2 C:\MyGames\Freeciv\libgdk-win32-2.0-0.dll:6C3463D2
gdk_drawable_get_visible_region
685ED10B C:\MyGames\Freeciv\libglib-2.0-0.dll:685ED10B
g_main_context_dispatch
685ED925 C:\MyGames\Freeciv\libglib-2.0-0.dll:685ED925
g_main_context_dispatch
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
00405DD7 _ui_main
004072ED _client_main
0040235B _console_main
00402418 _WinMain@16
00401AD6 _main
004010DB ___mingw_CRTStartup
00401158 _WinMainCRTStartup
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
wider questions:
* 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:
<http://gna.org/bugs/?20940>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
