Follow-up Comment #4, bug #21851 (project freeciv):

I intended to debug this, so built trunk@r24754 on kubuntu 13.10, and launched
freeciv-client with `G_SLICE=debug-blocks valgrind --tool=memcheck
--leak-check=full ./client/freeciv-gtk3` as recommended at

Unfortunately, valgrind complained it had found over 1000 different problems
by the time I had made a network connection to a local server (started with
`./server/freeciv-server`), and stopped reporting issues.  None of the
referenced leaks had pathnames anywhere near the freeciv source tree (all
being libraries, and most appearing to be pango).  I was unable to get output
from the city window open event (which does seem the most memory hungry). 
Even with --leak-resolution=low, I couldn't get as far as starting the game
before 1000 errors.

Could someone try duplicating this in a different operating environment, or
provide other suggestions to identify the offending code in more detail (yes,
it seems related to city windows, because one can observe the memory increase
when opening a city window using any of the various process information tools,
but understanding precisely where in the call stack it happens can help it be

For those trying to replicate the problem, any game with a couple cities is
enough, just keep opening and closing the city until you run out of memory for
the crash, or watch memory usage using some tool to watch it grow without the
potential for swapping out your desktop environment (or having the OOM killer
miss and terminate some other process you previously thought important).  That
said, I find it easier to replicate once I have 20 cities or so (in that it
tends to happen whether I am trying to poke the bug or leave it alone).


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to