[Freeciv-Dev] Re: (PR#6742) civclient memory leak

["Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=6742 >

On Sat, Nov 08, 2003 at 07:57:12PM -0800, Vasco Alexandre da Silva Costa wrote:
> 
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=6742 >
> 
> This patch should fix the leaks in update_menus and show_description.
> 
> I looked at the 'diff' file in 'leaks.tar.bz2', the other leaks seemed
> to be either GTK+ internal (I saw no Freeciv function calls in their
> trace), or text buffer memory. The text buffer is supposed to increase
> in size to log all the output from the game from start, so this doesn't
> look like a leak to me.
> 
> Please re-run valgrind and report any remaining leaks (especially large
> ones).

We are down to 68313 bytes leaked in 5 turns. All more or less deep
within gtk/gdk/x11.

I also started the client and open a lot of dialogs and closing
them. This resulted in a 900k leak. It is unknow if these are constant
leaks or if they happen every time this dialog is opened. Opening
dialogs is harder to reproduce then running 5 turns. To trace which
dialogs have problems I expanded the stack trace from 20 to 40. But
still no luck. I even tried "--num-callers=999999" but it looks like
the stack trace is limited to 50.

The top leaking one is this (I removed unknown entries in the stack
trace):

+ 22848 bytes in 357 blocks are still reachable in 
+    at 0x4003B9B4: malloc (vg_clientfuncs.c:100)
+    by 0x405E4A36: g_malloc (in /usr/lib/libglib-2.0.so.0.200.0)
+    by 0x40564169: pango_coverage_from_bytes (in 
/usr/lib/libpango-1.0.so.0.200.0)
+    by 0x405507AE: pango_x_face_get_coverage (in 
/usr/lib/libpangox-1.0.so.0.200.0)
+    by 0x4055F024: pango_font_get_coverage (in 
/usr/lib/libpango-1.0.so.0.200.0)
+    by 0x405646DC: pango_fontset_get_font (in /usr/lib/libpango-1.0.so.0.200.0)
+    by 0x40563094: pango_itemize (in /usr/lib/libpango-1.0.so.0.200.0)
+    by 0x40567AE6: pango_layout_get_extents (in 
/usr/lib/libpango-1.0.so.0.200.0)
+    by 0x405A1645: g_cclosure_marshal_VOID__BOXED (in 
/usr/lib/libgobject-2.0.so.0.200.0)
+    by 0x4058BF7A: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.200.0)
+    by 0x4059E61E: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.200.0)
+    by 0x4059F08D: g_signal_emit_by_name (in 
/usr/lib/libgobject-2.0.so.0.200.0)
+    by 0x4034EC3D: _gtk_size_group_compute_requisition (in 
/usr/lib/libgtk-x11-2.0.so.0.200.0)
+    by 0x403D93B6: gtk_widget_size_request (in 
/usr/lib/libgtk-x11-2.0.so.0.200.0)
+    by 0x405A1645: g_cclosure_marshal_VOID__BOXED (in 
/usr/lib/libgobject-2.0.so.0.200.0)
+    by 0x4058BF7A: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.200.0)
+    by 0x4059E61E: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.200.0)
+    by 0x4059F08D: g_signal_emit_by_name (in 
/usr/lib/libgobject-2.0.so.0.200.0)
+    by 0x4034EC3D: _gtk_size_group_compute_requisition (in 
/usr/lib/libgtk-x11-2.0.so.0.200.0)
+    by 0x403D93B6: gtk_widget_size_request (in 
/usr/lib/libgtk-x11-2.0.so.0.200.0)
+    by 0x405A1645: g_cclosure_marshal_VOID__BOXED (in 
/usr/lib/libgobject-2.0.so.0.200.0)
+    by 0x4058BF7A: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.200.0)
+    by 0x4059E61E: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.200.0)
+    by 0x4059F08D: g_signal_emit_by_name (in 
/usr/lib/libgobject-2.0.so.0.200.0)
+    by 0x4034EC3D: _gtk_size_group_compute_requisition (in 
/usr/lib/libgtk-x11-2.0.so.0.200.0)
+    by 0x403D93B6: gtk_widget_size_request (in 
/usr/lib/libgtk-x11-2.0.so.0.200.0)
+    by 0x405A0CAA: g_cclosure_marshal_VOID__VOID (in 
/usr/lib/libgobject-2.0.so.0.200.0)
+    by 0x4058BF7A: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.200.0)

Maybe someone on the gtk/pango lists can do something useful with this.

Also this one with _XEnq is quite common:

+ 19240 bytes in 185 blocks are still reachable in 
+    at 0x4003B9B4: malloc (vg_clientfuncs.c:100)
+    by 0x4084FF9A: _XEnq (in /usr/X11R6/lib/libX11.so.6.2)
+    by 0x4084F780: _XReply (in /usr/X11R6/lib/libX11.so.6.2)
+    by 0x40870026: _XkbHandleGetMapReply (in /usr/X11R6/lib/libX11.so.6.2)
+    by 0x408700C2: XkbGetUpdatedMap (in /usr/X11R6/lib/libX11.so.6.2)
+    by 0x40870155: XkbGetMap (in /usr/X11R6/lib/libX11.so.6.2)
+    by 0x404B7E42: gdk_keymap_translate_keyboard_state (in 
/usr/lib/libgdk-x11-2.0.so.0.200.0)
+    by 0x404AE1A5: _gdk_events_queue (in /usr/lib/libgdk-x11-2.0.so.0.200.0)
+    by 0x405E0A19: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.200.0)
+    by 0x405E1452: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.200.0)
+    by 0x4030BFF3: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.200.0)
+    by 0x808CFB6: ui_main (gui_main.c:1192)
+    by 0x8055084: main (civclient.c:247)
+    by 0x406721C4: __libc_start_main (in /lib/libc-2.2.5.so)

http://lists.trolltech.com/qt-interest/1997-08/thread00077-0.html mentions this.

For the record: I'm using the binary distribution (Linux-ix86-glibc22)
of XFree86 4.3.0.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 checking for the vaidity of the Maxwell laws on this machine... ok
 checking if e=mc^2... ok
 checking if we can safely swap on /dev/fd0... yes
    -- kvirc 2.0.0's configure