bugFreeciv - Bugs: bug #21851, Possible memory leak in city...

 
 
Show feedback again

bug #21851: Possible memory leak in city dialog (in X server?)

Submitted by:  David Fernandez <bardo>
Submitted on:  Fri 21 Mar 2014 06:17:31 AM UTC  
 
Category: client-gtk-2.0Severity: 3 - Normal
Priority: 5 - NormalStatus: None
Assigned to: NoneOpen/Closed: Open
Release: Operating System: None
Planned Release: 2.5.2, 2.6.0, 3.0.0

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Thu 05 Feb 2015 04:34:15 AM UTC, comment #27:

I'm afraid the patch from bug #21942 fixes gtk3, but does not fix this problem with gtk2 (if I patched and tested it properly).

I keep noticing 2 causes of memory leak with gtk2:
1) huge leak while scrolling the production dropdown menu.
2) smaller leak (between 500KB and 1MB in my test) every time I open and close a city dialog (without doing anything else).

This 2nd case confirmed by <jorneg> and <persia> in previous posts.

>when one changes to "Next" or "Prev" city. Does the usage of those buttons cause similar memory consumption problem for you?

The use of those buttons do not seem to leak memory in my case, nor the use of the production tab. Only when I close the city window and I open a new one.

Fortunately, while testing gtk3 client, there is no noticeable leakeage: the memory usage increases in those 2 cases, but then it is properly freed after the city dialog is closed.

David Fernandez <bardo>
Wed 04 Feb 2015 11:28:20 PM UTC, comment #26:

>What is version of your gtk?

libgtk-2: 2.24.23-0
libgtk-3: 3.10.8-0

My SO: Kubuntu 14.04
Kernel: 3.13.0-44-generic
KDE: 4.13.3

gtk-3 client still crashes for me when I try to open a city dialog (S2_5 rev27747). I reported it in bug #21942.

David Fernandez <bardo>
Wed 04 Feb 2015 08:40:41 PM UTC, comment #25:

When I first reported this problem, I tested both available themes (default and oxygen) and I noticed similar memory problems, as I said in a previous post. But I think there are different causes of memory leak here.

The problem while scrolling the dropdown menu is reduced a bit when I use freeciv default theme, I think because the items are sorted in 3 columns, and there is less room to scroll. The memory leak is still very noticeable though.

I have tested different tilesets just in case, and there is no difference when I use trident, isotrident or amplio2.

I'm testing now to play without using this problematic menu, and the leak is much more subtle now, but I keep seing that the memory usage grows while I play, I'll keep testing to detect the exact triggers.

Anyway, thank you for the help, at least now I know how to avoid the worst effects.

David Fernandez <bardo>
Wed 04 Feb 2015 06:02:48 AM UTC, comment #24:

I were about to ask if changing the theme affects this, as freeciv theme's background image has been involved in many many problems in the past, but your screenshot shows that you're not even using freeciv's own theme.
Maybe it's still worth testing the other way around: does changing the theme to freeciv's own have any effect on this.

I would still be interested to know if gtk3-client is similarly affected.

What is version of your gtk?

Otherwise I'm out of ideas at the moment. I found a bunch of other problems, and fixed them, as a result of this hunt, though, so it was not an completely wasted effort.

Marko Lindqvist <cazfi>
Project Administrator
Mon 02 Feb 2015 10:09:51 PM UTC, comment #23:

I have tested the patch #5776 and I'm afraid it does not fix the memory leak. (S2_5 rev27747 with gtk-2 client)

I found that the main trigger of the memory leak is actually to scroll down and up the list of items, even if the items are not really selected nor highlighted.

I attach 2 screenshots where you can see the increase of memory usage by the Xorg process from 100 MB to 470 MB in a few seconds:
-1st screen as reference, with the city dialog already opened.
-2nd screen after I click the dropdown menu, and then I scroll up and down during some seconds.
Those 400 MB are not freed until I close freeciv.

(file #23699, file #23700)

David Fernandez <bardo>
Mon 02 Feb 2015 02:17:22 AM UTC, comment #22:

After some more tests, I think you are right, the key factor is the selection of a item in the dropdown menu. No need to click it, just to move the mouse over the items, and the memory usage of Xorg increase a ridiculous amount, up to 100 MB in my tests!!, that are never recovered once the city dialog is closed.

I can reproduce it whenever I want now. I simply open a city dialog, click the dropdown menu, then I move the mouse up and down over the items for some time, then I close the menu without selecting anything, I close the city dialog, and the memory usage of Xorg increase from the initial 100 MB, to 200 MB or so. If I repeat with another city, it increases to 300 MB, and so on until my pc runs out of memory.

I'll test that patch.

David Fernandez <bardo>
Sun 01 Feb 2015 11:40:57 PM UTC, comment #21:

> If I actually choose something from the menu, Xorg takes a lot
> of memory and that's not restored for some time.


That seems to correlate with the fact that the menu opens on top of city improvements list -> once the menu closes, pointer is on top of improvements list -> often times tooltip of that list opens. The memory consumption seems a bit high for such a simple widget as the tooltip opened, but after removing the tooltip from the source code completely this high memory consumption disappears.

patch #5776 is related to this.

Marko Lindqvist <cazfi>
Project Administrator
Sun 01 Feb 2015 11:04:34 PM UTC, comment #20:

>If I actually choose something from the menu, Xorg takes a lot of memory and that's not restored for some time.

That is similar to what I noticed. Most of my pc freezes occurred at that point, just when I press a item in the drop down menu.

I can't be sure if the memory of the dropdown menu is restored later in my case too, because I simply monitorized it by eye. But I'm sure that, the more I open the city dialogs, the bigger the memory usage.

>Does the usage of those buttons cause similar memory consumption problem for you?

Now that you say it, I actually try to use those buttons because I did notice that they do not cause the same memory consumption than closing the window and opening a new city dialog. But I have not measured it objectively.

This is an important problem that makes it hard for me to play in my laptop, please tell me if I can run some tool to help with the diagnosis.

David Fernandez <bardo>
Sun 01 Feb 2015 09:16:35 PM UTC, comment #19:

I can't reproduce any lasting memory loss (sometimes it takes a while for things to settle).

When I first open the dropdown menu, Xorg takes a bit more memory. If I then cancel the menu (click the arrow again), the memory is immediately restored. If I actually choose something from the menu, Xorg takes a lot of memory and that's not restored for some time.

Though that memory usage is not necessarily any way related to your problem, I tracked it down to the fact that production change request is sent to the server, server sends an updated city info with the changed production target, and the already open city dialog gets refreshed in its entirety (so the problem can be in any element of the dialog, not necessarily in the production menu (which I assume gtk to close already before the server response gets handled))

In addition to handling of the server sent message, there's another case where real_city_dialog_refresh() gets called for open dialog: when one changes to "Next" or "Prev" city. Does the usage of those buttons cause similar memory consumption problem for you?

Marko Lindqvist <cazfi>
Project Administrator
Sun 01 Feb 2015 06:19:54 PM UTC, comment #18:

>In the "Overview" tab?

Yes, for some reason I find it faster here than changing the tab.

>Does using the "Production" -tab cause similar memory problem?

I admit I hardly use the production tab, so I can't tell.

I'll test to use the tab instead of the dropdown menu, to see if I notice an improvement.

David Fernandez <bardo>
Sun 01 Feb 2015 04:35:44 PM UTC, comment #17:

> If it helps, in my case, the event that increase the memory
> usage the most is the use of the dropdown menu to change the
> production in the city window.


In the "Overview" tab? I almost never use that myself, using the worklist even when I want to modify just the current production (first item in the list). Does it work as a workaround for you, or does using the "Production" -tab cause similar memory problem?

Marko Lindqvist <cazfi>
Project Administrator
Sun 01 Feb 2015 04:17:43 PM UTC, comment #16:

If it helps, in my case, the event that increase the memory usage the most is the use of the dropdown menu to change the production in the city window.

This problem used to force me to restart the system when running out of memory, but I learnt to avoid it by changing the swappiness to 10 (it was 60 by default), as suggested here: https://help.ubuntu.com/community/SwapFaq

Now, I just need to close freeciv and open it again when getting slow. At the end of the game, once every turn or so, but I have only 2GB RAM.

David Fernandez <bardo>
Sun 01 Feb 2015 02:38:18 PM UTC, comment #15:

I can reproduce the leak in the X server (1.16.3, Arch version) with Freeciv 2.4.4 (Gtk 2 client). As far as I remember, this problem has been around for a long time (all I can say is it was likely not present before Amplio became the default). The memory usage of the X server goes down when Freeciv is closed.
I got no Valgrind output for the Gtk 2 client (logical, the memory belongs to X).

Having investigated two possible causes:

  • The leak is not in the 'Present units' list (moving units back and forth doesn't increase memory usage)
  • The leak is not in the 'Buildings' list (adding and removing buildings using the editor doesn't increase memory usage)
Louis Moureaux <louis94>
Sun 01 Feb 2015 01:17:12 PM UTC, comment #14:

Does this still happen with current Ubuntu versions? Is this freeciv-2.5 regression compared to freeciv-2.4?

If it's an regression and affects current OS versions, this seems like a freeciv-2.5.0 blocker.

Is gtk2-client the only client affected, or does gtk3-client have the same behavior?

Marko Lindqvist <cazfi>
Project Administrator
Tue 22 Apr 2014 12:42:52 AM UTC, comment #13:

I think you are right about X server, jtn.

>Can you spot any other process' memory usage increasing?

In my case, the process "freeciv-gtk2" keeps constant memory usage, "kwin" changes when I open window, but it returns to similar memory usage when I close it.

It is Xorg process that increases the "shared memory" (2nd column of the system monitor) a lot (5000K or so) everytime I open a window, and more if I click the production dropdown menu.
And it keeps growing if I continue playing, from 100M at start, to 200M in 5 min of average gameplay.

David Fernandez <bardo>
Mon 21 Apr 2014 08:21:58 PM UTC, comment #12:

> (jorneg writes: "You continue to have the same problem with Ubuntu 12.04" ... do you mean that you, jorneg, have the same problem?)

Yes, I refer to me, sorry.

Jordi Negrevernis i Font <jorneg>
Project Member
Mon 21 Apr 2014 02:50:45 PM UTC, comment #11:

bardo writes [Kubuntu 13.10]:

> When I monitor the memory usage (Kinfocenter), the free
> memory clearly decreases when I open a city window [...]
> However, the memory used by freeciv, as reported by the
> process monitor, remains the same.


whereas jorneg writes [Ubuntu 12.04 Unity?]:

> To see the problem I use the system monitor of gnome. Every
> time you open a city window the overall memory of the
> process freeciv-gtk2 increases...


Taken at face value, these seem to be two different symptoms, unless the two process monitors are reporting different measures of process memory usage.

In bardo's case, I wonder if the leak is somewhere like the X server -- could we be causing images/textures to leak within the X server? Can you spot any other process' memory usage increasing?

(jorneg writes: "You continue to have the same problem with Ubuntu 12.04" ... do you mean that you, jorneg, have the same problem?)

Jacob Nevins <jtn>
Project Administrator
Mon 21 Apr 2014 02:24:27 PM UTC, comment #10:

You continue to have the same problem with Ubuntu 12.04 ( with the Unity interface)...

To see the problem I use the system monitor of gnome. Every time you open a city window the overall memory of the process freeciv-gtk2 increases...

It could be that we are leaking gtk handles?

Jordi Negrevernis i Font <jorneg>
Project Member
Sun 20 Apr 2014 12:35:23 AM UTC, comment #9:

My case is exactly as described by Emmet Hikory (also with Kubuntu 13.10).
When the game advances and I have a lot of cities (100 or so), I have to close freeciv and relaunch it every turn. If I try to play 2 consecutive turns, my pc uses to get hang, but as Emmet Hikory, I use to open/close the city window once per city and per turn.

When I monitor the memory usage (Kinfocenter), the free memory clearly decreases when I open a city window, I use the dropdown menu to change the production, and then I close the window, but I'd be unable to measure it this way. However, the memory used by freeciv, as reported by the process monitor, remains the same.

David Fernandez <bardo>
Sat 19 Apr 2014 05:31:50 PM UTC, comment #8:

I had a quick go at reproducing this problem, but didn't see any obvious leakage on my system (Xubuntu 12.04 -- that's Xfce -- and head of Freeciv S2_5 svn == r24779 freeciv-gtk2, amplio2hexbig tileset) -- opening and closing city dialogs from an existing savegame with many cities, I didn't see any obvious growth in either the VIRT or RES columns of 'top' (they stay at "674m" and "212m" respectively).

Comment #1:

> The cost of opening the city windows and closing it is between
> 1 & 2MB leaked.

How did you measure this?

> This is in Ubuntu 10.04.

That's pre-Unity, so I'm guessing the desktop environment is GNOME 2?

However, since it's also seen on Kubuntu 13.10, it seems unlikely to be related to deskop environment.

(I vaguely wonder if bug #20685 is somehow related, although it seems unlikely.)

Jacob Nevins <jtn>
Project Administrator
Mon 14 Apr 2014 10:49:48 PM UTC, comment #7:

I'm able to go to the city window (S2_4 on ubuntu 12.04) without the suppression file seeing the results of valgrind... It must be your distribution...

Note: the are a lot of errors on system libraries...

This is the last part:

==2711== by 0x402A4DE: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41AB2E1: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41F76FF: g_slice_alloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41F7795: g_slice_alloc0 (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x4884677: g_type_create_instance (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x4867507: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x4869230: g_object_newv (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x48697C7: g_object_new (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x479AA88: ??? (in /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0.2400.10)
==2711== by 0x4763370: gdk_pixmap_new (in /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0.2400.10)
==2711== by 0x4762206: gdk_pixbuf_render_pixmap_and_mask_for_colormap (in /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0.2400.10)
==2711==
==2711== 32,488 bytes in 131 blocks are possibly lost in loss record 9,804 of 9,845
==2711== at 0x402A420: memalign (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x402A4DE: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41AB2E1: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41F76FF: g_slice_alloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41FAEA9: g_string_sized_new (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41FB4E6: g_string_new (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41C8F9D: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41CA854: g_build_filename (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x43D3269: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x43D3399: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x43D3399: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x43D3399: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711==
==2711== 36,864 bytes in 6 blocks are possibly lost in loss record 9,807 of 9,845
==2711== at 0x402A5E6: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E2752: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2E6A: g_malloc0 (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x4E786E8: ??? (in /usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0.3000.0)
==2711== by 0x4E7AFC5: ??? (in /usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0.3000.0)
==2711== by 0x481994B: pango_font_get_glyph_extents (in /usr/lib/i386-linux-gnu/libpango-1.0.so.0.3000.0)
==2711== by 0x50D614B: pango_ot_buffer_output (in /usr/lib/i386-linux-gnu/libpangoft2-1.0.so.0.3000.0)
==2711== by 0x7EA5DDA: ??? (in /usr/lib/i386-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so)
==2711== by 0x48224AC: ??? (in /usr/lib/i386-linux-gnu/libpango-1.0.so.0.3000.0)
==2711== by 0x4833B9B: pango_shape (in /usr/lib/i386-linux-gnu/libpango-1.0.so.0.3000.0)
==2711== by 0x4813AE8: ??? (in /usr/lib/i386-linux-gnu/libpango-1.0.so.0.3000.0)
==2711== by 0x4813DD3: ??? (in /usr/lib/i386-linux-gnu/libpango-1.0.so.0.3000.0)
==2711==
==2711== 41,416 bytes in 167 blocks are possibly lost in loss record 9,811 of 9,845
==2711== at 0x402A420: memalign (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x402A4DE: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41AB2E1: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41F76FF: g_slice_alloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41F7795: g_slice_alloc0 (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x4884677: g_type_create_instance (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x4867507: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x4869230: g_object_newv (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x48697C7: g_object_new (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x479AA88: ??? (in /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0.2400.10)
==2711== by 0x4763370: gdk_pixmap_new (in /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0.2400.10)
==2711== by 0x476237F: gdk_pixbuf_render_pixmap_and_mask_for_colormap (in /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0.2400.10)
==2711==
==2711== 49,080 bytes in 1 blocks are possibly lost in loss record 9,812 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2F81: g_try_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x47EE4A1: gdk_pixbuf_copy (in /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==2711== by 0x80A6BB4: crop_sprite (sprite.c:66)
==2711== by 0x80F9050: load_sprite.isra.10 (tilespec.c:1971)
==2711== by 0x80FA2F2: tileset_lookup_sprite_tags (tilespec.c:2268)
==2711== by 0x80FF1AE: tileset_load_tiles (tilespec.c:2733)
==2711== by 0x8083F65: ui_main (gui_main.c:1642)
==2711== by 0x80B26C7: client_main (client_main.c:590)
==2711== by 0x80802FA: main (gui_main.c:1508)
==2711==
==2711== 49,080 bytes in 1 blocks are possibly lost in loss record 9,813 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2F81: g_try_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x47EE4A1: gdk_pixbuf_copy (in /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==2711== by 0x80A6BB4: crop_sprite (sprite.c:66)
==2711== by 0x80F9050: load_sprite.isra.10 (tilespec.c:1971)
==2711== by 0x80FA3DF: tileset_lookup_sprite_tags (tilespec.c:2281)
==2711== by 0x80FF1AE: tileset_load_tiles (tilespec.c:2733)
==2711== by 0x8083F65: ui_main (gui_main.c:1642)
==2711== by 0x80B26C7: client_main (client_main.c:590)
==2711== by 0x80802FA: main (gui_main.c:1508)
==2711==
==2711== 49,152 bytes in 1 blocks are possibly lost in loss record 9,814 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2E02: g_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x476A8BD: ??? (in /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0.2400.10)
==2711== by 0x476A9A4: ??? (in /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0.2400.10)
==2711== by 0x476AE0D: ??? (in /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0.2400.10)
==2711== by 0x476CBC3: gdk_draw_rgb_32_image (in /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0.2400.10)
==2711== by 0x47622A9: gdk_pixbuf_render_pixmap_and_mask_for_colormap (in /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0.2400.10)
==2711== by 0x476241F: gdk_pixbuf_render_pixmap_and_mask (in /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0.2400.10)
==2711== by 0x80A66B3: ctor_sprite (sprite.c:187)
==2711== by 0x80F9050: load_sprite.isra.10 (tilespec.c:1971)
==2711== by 0x80FA2BA: tileset_lookup_sprite_tags (tilespec.c:2264)
==2711==
==2711== 61,376 bytes in 8 blocks are possibly lost in loss record 9,817 of 9,845
==2711== at 0x402A420: memalign (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x402A4DE: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41AB2E1: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41F76D7: g_slice_alloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41F7795: g_slice_alloc0 (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x4884677: g_type_create_instance (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x4867507: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x4869230: g_object_newv (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x48697C7: g_object_new (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x445AD46: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x445CD41: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x44617DA: gtk_rc_get_style (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711==
==2711== 73,824 bytes in 1,538 blocks are possibly lost in loss record 9,819 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2E02: g_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x43D328A: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x43D3399: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x43D3399: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x43D3399: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x43D4D3C: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x43D5F31: gtk_icon_theme_has_icon (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x4334577: gtk_action_group_add_actions_full (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x433468E: gtk_action_group_add_actions (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x80805CF: idle_callback_wrapper (gui_main.c:2049)
==2711==
==2711== 86,016 bytes in 42 blocks are possibly lost in loss record 9,822 of 9,845
==2711== at 0x402BF52: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E2722: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2ED8: g_realloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41AE4B4: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41AEAEA: g_array_insert_vals (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x445AF18: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x445B167: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x753AFFA: ??? (in /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/engines/libmurrine.so)
==2711== by 0x445CD57: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x44617DA: gtk_rc_get_style (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x454B2B7: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x448639F: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711==
==2711== 92,820 bytes in 51 blocks are possibly lost in loss record 9,823 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2E02: g_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41F722D: g_slice_alloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41F7795: g_slice_alloc0 (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x4884677: g_type_create_instance (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x4867507: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x4869230: g_object_newv (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x48697C7: g_object_new (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x753ACD1: ??? (in /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/engines/libmurrine.so)
==2711== by 0x445CDC9: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x44617DA: gtk_rc_get_style (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711==
==2711== 98,432 bytes in 1,538 blocks are possibly lost in loss record 9,824 of 9,845
==2711== at 0x402BF52: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E2722: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2ED8: g_realloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41FAE76: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41FB182: g_string_insert_len (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41FB497: g_string_append_len (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41C9144: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41CA854: g_build_filename (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x43D3269: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x43D3399: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x43D3399: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711== by 0x43D3399: ??? (in /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2711==
==2711== 110,592 bytes in 9 blocks are possibly lost in loss record 9,825 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2F81: g_try_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x47EDAFE: gdk_pixbuf_new (in /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==2711== by 0x80A698B: sprite_get_pixbuf (sprite.c:368)
==2711== by 0x812C79E: editgui_tileset_changed (editgui.c:885)
==2711== by 0x80B39E4: set_client_state (client_main.c:822)
==2711== by 0x80DE944: handle_start_phase (packhand.c:1115)
==2711== by 0x80E5700: client_handle_packet (packhand_gen.c:233)
==2711== by 0x80B1FF4: client_packet_input (client_main.c:654)
==2711== by 0x80B920F: input_from_server (clinet.c:421)
==2711== by 0x8080626: get_net_input (gui_main.c:1882)
==2711==
==2711== 133,560 bytes in 265 blocks are possibly lost in loss record 9,826 of 9,845
==2711== at 0x402A420: memalign (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x402A4DE: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41AB2E1: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41F76FF: g_slice_alloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41F7795: g_slice_alloc0 (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x4884677: g_type_create_instance (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x4867507: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x4869230: g_object_newv (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x48697C7: g_object_new (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x4762EC3: ??? (in /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0.2400.10)
==2711== by 0x488470A: g_type_create_instance (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711== by 0x4867507: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2711==
==2711== 180,864 bytes in 1 blocks are possibly lost in loss record 9,827 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2F81: g_try_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x47EE4A1: gdk_pixbuf_copy (in /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==2711== by 0x80A6BB4: crop_sprite (sprite.c:66)
==2711== by 0x80F9050: load_sprite.isra.10 (tilespec.c:1971)
==2711== by 0x80FC523: tileset_lookup_sprite_tags (tilespec.c:2332)
==2711== by 0x80FF1AE: tileset_load_tiles (tilespec.c:2733)
==2711== by 0x8083F65: ui_main (gui_main.c:1642)
==2711== by 0x80B26C7: client_main (client_main.c:590)
==2711== by 0x80802FA: main (gui_main.c:1508)
==2711==
==2711== 180,864 bytes in 1 blocks are possibly lost in loss record 9,828 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2F81: g_try_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x47EE4A1: gdk_pixbuf_copy (in /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==2711== by 0x80A6BB4: crop_sprite (sprite.c:66)
==2711== by 0x80F9050: load_sprite.isra.10 (tilespec.c:1971)
==2711== by 0x80FB21D: tileset_lookup_sprite_tags (tilespec.c:2541)
==2711== by 0x80FF1AE: tileset_load_tiles (tilespec.c:2733)
==2711== by 0x8083F65: ui_main (gui_main.c:1642)
==2711== by 0x80B26C7: client_main (client_main.c:590)
==2711== by 0x80802FA: main (gui_main.c:1508)
==2711==
==2711== 180,864 bytes in 1 blocks are possibly lost in loss record 9,829 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2F81: g_try_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x47EE4A1: gdk_pixbuf_copy (in /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==2711== by 0x80A6BB4: crop_sprite (sprite.c:66)
==2711== by 0x80F9050: load_sprite.isra.10 (tilespec.c:1971)
==2711== by 0x80FB239: tileset_lookup_sprite_tags (tilespec.c:2542)
==2711== by 0x80FF1AE: tileset_load_tiles (tilespec.c:2733)
==2711== by 0x8083F65: ui_main (gui_main.c:1642)
==2711== by 0x80B26C7: client_main (client_main.c:590)
==2711== by 0x80802FA: main (gui_main.c:1508)
==2711==
==2711== 180,864 bytes in 1 blocks are possibly lost in loss record 9,830 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2F81: g_try_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x47EE4A1: gdk_pixbuf_copy (in /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==2711== by 0x80A6BB4: crop_sprite (sprite.c:66)
==2711== by 0x80F9050: load_sprite.isra.10 (tilespec.c:1971)
==2711== by 0x80FB255: tileset_lookup_sprite_tags (tilespec.c:2543)
==2711== by 0x80FF1AE: tileset_load_tiles (tilespec.c:2733)
==2711== by 0x8083F65: ui_main (gui_main.c:1642)
==2711== by 0x80B26C7: client_main (client_main.c:590)
==2711== by 0x80802FA: main (gui_main.c:1508)
==2711==
==2711== 180,864 bytes in 1 blocks are possibly lost in loss record 9,831 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2F81: g_try_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x47EE4A1: gdk_pixbuf_copy (in /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==2711== by 0x80A6BB4: crop_sprite (sprite.c:66)
==2711== by 0x80F9050: load_sprite.isra.10 (tilespec.c:1971)
==2711== by 0x80FB705: tileset_lookup_sprite_tags (tilespec.c:2622)
==2711== by 0x80FF1AE: tileset_load_tiles (tilespec.c:2733)
==2711== by 0x8083F65: ui_main (gui_main.c:1642)
==2711== by 0x80B26C7: client_main (client_main.c:590)
==2711== by 0x80802FA: main (gui_main.c:1508)
==2711==
==2711== 180,864 bytes in 1 blocks are possibly lost in loss record 9,832 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2F81: g_try_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x47EE4A1: gdk_pixbuf_copy (in /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==2711== by 0x80A6BB4: crop_sprite (sprite.c:66)
==2711== by 0x80F9050: load_sprite.isra.10 (tilespec.c:1971)
==2711== by 0x80FB78D: tileset_lookup_sprite_tags (tilespec.c:2631)
==2711== by 0x80FF1AE: tileset_load_tiles (tilespec.c:2733)
==2711== by 0x8083F65: ui_main (gui_main.c:1642)
==2711== by 0x80B26C7: client_main (client_main.c:590)
==2711== by 0x80802FA: main (gui_main.c:1508)
==2711==
==2711== 180,864 bytes in 1 blocks are possibly lost in loss record 9,833 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2F81: g_try_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x47EE4A1: gdk_pixbuf_copy (in /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==2711== by 0x80A6BB4: crop_sprite (sprite.c:66)
==2711== by 0x80F9050: load_sprite.isra.10 (tilespec.c:1971)
==2711== by 0x80FBB03: tileset_lookup_sprite_tags (tilespec.c:2636)
==2711== by 0x80FF1AE: tileset_load_tiles (tilespec.c:2733)
==2711== by 0x8083F65: ui_main (gui_main.c:1642)
==2711== by 0x80B26C7: client_main (client_main.c:590)
==2711== by 0x80802FA: main (gui_main.c:1508)
==2711==
==2711== 180,864 bytes in 1 blocks are possibly lost in loss record 9,834 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2F81: g_try_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x47EE4A1: gdk_pixbuf_copy (in /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==2711== by 0x80A6BB4: crop_sprite (sprite.c:66)
==2711== by 0x80F9050: load_sprite.isra.10 (tilespec.c:1971)
==2711== by 0x8100424: tileset_setup_tile_type (tilespec.c:3221)
==2711== by 0x80E32AB: handle_ruleset_terrain (packhand.c:3068)
==2711== by 0x80E55BD: client_handle_packet (packhand_gen.c:312)
==2711== by 0x80B1FF4: client_packet_input (client_main.c:654)
==2711== by 0x80B920F: input_from_server (clinet.c:421)
==2711== by 0x8080626: get_net_input (gui_main.c:1882)
==2711==
==2711== 3,617,280 bytes in 20 blocks are possibly lost in loss record 9,841 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2F81: g_try_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x47EE4A1: gdk_pixbuf_copy (in /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==2711== by 0x80A6BB4: crop_sprite (sprite.c:66)
==2711== by 0x80F9050: load_sprite.isra.10 (tilespec.c:1971)
==2711== by 0x80FA03F: tiles_lookup_sprite_tag_alt (tilespec.c:2754)
==2711== by 0x80FF3F9: tileset_setup_resource (tilespec.c:2891)
==2711== by 0x80E3413: handle_ruleset_resource (packhand.c:3088)
==2711== by 0x80E5490: client_handle_packet (packhand_gen.c:379)
==2711== by 0x80B1FF4: client_packet_input (client_main.c:654)
==2711== by 0x80B920F: input_from_server (clinet.c:421)
==2711==
==2711== 10,117,632 bytes in 42 blocks are possibly lost in loss record 9,845 of 9,845
==2711== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2711== by 0x41E296A: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x41E2F81: g_try_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2711== by 0x47EE4A1: gdk_pixbuf_copy (in /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==2711== by 0x80A6BB4: crop_sprite (sprite.c:66)
==2711== by 0x80F9050: load_sprite.isra.10 (tilespec.c:1971)
==2711== by 0x80F9449: tileset_setup_unit_type_from_tag (tilespec.c:2806)
==2711== by 0x80FF1F2: tileset_setup_unit_type (tilespec.c:2840)
==2711== by 0x80E2265: handle_ruleset_unit (packhand.c:2884)
==2711== by 0x80E5683: client_handle_packet (packhand_gen.c:264)
==2711== by 0x80B1FF4: client_packet_input (client_main.c:654)
==2711== by 0x80B920F: input_from_server (clinet.c:421)
==2711==
==2711== LEAK SUMMARY:
==2711== definitely lost: 82,783 bytes in 2,559 blocks
==2711== indirectly lost: 30,548 bytes in 1,537 blocks
==2711== possibly lost: 18,474,520 bytes in 29,058 blocks
==2711== still reachable: 22,862,411 bytes in 46,242 blocks
==2711== suppressed: 0 bytes in 0 blocks
==2711== Reachable blocks (those to which a pointer was found) are not shown.
==2711== To see them, rerun with: --leak-check=full --show-reachable=yes
==2711==
==2711== For counts of detected and suppressed errors, rerun with: -v
==2711== ERROR SUMMARY: 6437 errors from 4769 contexts (suppressed: 0 from 0)
jordi@ubuntu12:~/freeciv/S2_4/freeciv-2.4$

Jordi Negrevernis i Font <jorneg>
Project Member
Mon 14 Apr 2014 02:12:36 AM UTC, comment #6:

Unfortunately, even with the suppressions file loaded (adding --suppressions=scripts/freeciv.supp to the command line), valgrind stops processing before being able to open city windows (or even starting the game: connecting to the server and loading a savegame is enough to surpass the threshold). Does this happen for other operating environments, or is it unique to Kubuntu 13.10 (or even Kubuntu in general)?

To underscore the severity of the problem, as a player who enjoys direct management of cities, and typically opens each city dialog once or twice per turn, even with 16GB RAM, I cannot play a single turn once I have a reasonable number of cities without overflowing available memory (making the use of the client frustrating, as the typical turn involves several restarts (one launch for turn change and reaction to turn change messages (including city dialog inspection), one launch for unit management (including city dialog inspection for trade routes, engineering, assignment of defense forces, etc.), and two or more launches reviewing the happiness, pollution, worklists, etc.).

Emmet Hikory <persia>
Project Member
Sun 13 Apr 2014 08:02:45 PM UTC, comment #5:

About running valgrind for freeciv: Note that we have suppressions file scripts/freeciv.supp available.

Marko Lindqvist <cazfi>
Project Administrator
Fri 11 Apr 2014 11:09:59 PM UTC, comment #4:

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 http://stackoverflow.com/questions/16659781/memory-leaks-in-gtk-hello-world-program .

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 solved).

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).

Emmet Hikory <persia>
Project Member
Thu 10 Apr 2014 04:17:07 PM UTC, comment #3:

This issue get worse with time for me. At the end of the game my freeciv was crashing every 2 or 3 turns due to lack of memory...
I confirm it is not related to windows themes (oxygen or default).

Latest tests with rev24753.

David Fernandez <bardo>
Sat 22 Mar 2014 11:33:02 AM UTC, comment #2:

I agree it seems related to the city windows.
Mine is kubuntu 13.10. I'm usign "oxygen-gtk" as theme in freeciv options, instead of the default one.
Next time I'll try a different theme to see if this is the cause.

David Fernandez <bardo>
Fri 21 Mar 2014 03:02:23 PM UTC, comment #1:

Yes.

The cost of opening the city windows and closing it is between 1 & 2MB leaked. This is in Ubuntu 10.04.

Jordi Negrevernis i Font <jorneg>
Project Member
Fri 21 Mar 2014 06:17:31 AM UTC, original submission:

I have been playing freeciv v2.5 these days (compiled from source, rev 24652, under kubuntu) and I have noticed that my laptop runs out of memory (2GB) when I play for several hours. It has happened several times, and it uses to end with a forced close of freeciv-gtk2 due to "lack of memory" and a forced restart of my pc.

It is very noticeable when it starts using swap and I can hear the continuos write on disk. If I monitor the memory, I can see how it runs out of phisical ram, sort after that I start losing the control of my pc (mouse, ctrl+alt+supr, and even ctrl+alt+F1), and if I do not kill freeciv process, some time later the pc is automatically restarted.

If I close freeciv when it starts using swap memory, and I relaunch it, I can continue playing without problems.

I think I can recreate it, tell me if there is someway to get useful info. Once, I tried to run freeciv from gdb, but there are no error messages, nor core dumped... the pc just runs out of memory and it is forced to restart with a message like "freeciv-gtk2 killed due to lack of memory, the system is going to shut down".

David Fernandez <bardo>

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #23699:  leak0.jpg added by bardo (136kB - image/jpeg)
file #23700:  leak1.jpg added by bardo (133kB - image/jpeg)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by louis94 (Posted a comment)
  • -unavailable- added by jtn (Posted a comment)
  • -unavailable- added by cazfi (Updated the item)
  • -unavailable- added by persia (Posted a comment)
  • -unavailable- added by jorneg (Posted a comment)
  • -unavailable- added by bardo (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 07 Aug 2015 06:18:35 PM UTCcazfiPlanned Release2.5.1, 2.6.0, 3.0.0=>2.5.2, 2.6.0, 3.0.0
    Sat 21 Feb 2015 12:33:04 PM UTCcazfiPlanned Release2.5.0,2.6.0=>2.5.1, 2.6.0, 3.0.0
    Wed 18 Feb 2015 09:46:54 PM UTCcazfiSummaryPossible memory leak in S2_5 (in X server?)=>Possible memory leak in city dialog (in X server?)
    Mon 02 Feb 2015 10:09:51 PM UTCbardoAttached File-=>Added leak0.jpg, #23699
      Attached File-=>Added leak1.jpg, #23700
    Tue 15 Jul 2014 08:12:52 PM UTCjtnSummaryPossible memory leak in S2_5=>Possible memory leak in S2_5 (in X server?)
    Sat 19 Apr 2014 05:31:50 PM UTCjtnPlanned Release=>2.5.0,2.6.0
    Sun 13 Apr 2014 07:51:55 PM UTCcazfiCategoryNone=>client-gtk-2.0
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup