[Pidgin] #8498: memory leaks

[Pidgin]

#8498: memory leaks
-----------------------------+----------------------------------------------
 Reporter:  brian_j_murrell  |           Owner:  lschiere    
     Type:  defect           |          Status:  new         
Milestone:                   |       Component:  unclassified
  Version:  2.5.2            |      Resolution:              
 Keywords:                   |   Launchpad_bug:              
-----------------------------+----------------------------------------------

Comment(by brian_j_murrell):

 Replying to [comment:1 deryni]:
 > There are a couple of leaks in qq, a couple in otr, and a couple in
 gstreamer
 > most of which are on the smaller side (the otr ones are bigger than the
 > others as they involve icons).

 This one looks pretty big.  At least as big as the alleged (see below)
 pango/fontconfig leaks:

 ==25684== 675,703 (61,528 direct, 614,175 indirect) bytes in 707 blocks
 are definitely lost in loss record 317 of 331
 ==25684==    at 0x4025D2E: malloc (vg_replace_malloc.c:207)
 ==25684==    by 0x47A8D63: g_malloc (gmem.c:131)
 ==25684==    by 0x47BF8E2: g_slice_alloc (gslice.c:824)
 ==25684==    by 0x47BFC14: g_slice_alloc0 (gslice.c:833)
 ==25684==    by 0x4754E0A: g_type_create_instance (gtype.c:1654)
 ==25684==    by 0x47393D4: g_object_constructor (gobject.c:1334)
 ==25684==    by 0x4739C05: g_object_newv (gobject.c:1211)
 ==25684==    by 0x473A801: g_object_new_valist (gobject.c:1315)
 ==25684==    by 0x473A94D: g_object_new (gobject.c:1056)
 ==25684==    by 0x46AC471: gdk_pixbuf_new_from_data (gdk-pixbuf-data.c:65)
 ==25684==    by 0x46A9EC4: gdk_pixbuf_new (gdk-pixbuf.c:273)
 ==25684==    by 0x743ED07: gdk_pixbuf__png_image_load (io-png.c:303)
 ==25684==    by 0x46AE07F: _gdk_pixbuf_generic_image_load (gdk-pixbuf-
 io.c:1055)
 ==25684==    by 0x46AEE53: gdk_pixbuf_new_from_file (gdk-pixbuf-io.c:1167)
 ==25684==    by 0x80FCA53: pidgin_create_prpl_icon_from_prpl
 (gtkutils.c:610)
 ==25684==    by 0x80FF424: pidgin_create_prpl_icon (gtkutils.c:1758)
 ==25684==    by 0x5EECD0F: ???
 ==25684==    by 0x5EED44D: ???
 ==25684==    by 0x5EEDCC9: ???
 ==25684==    by 0x5EEE01D: ???
 ==25684==    by 0x5EEE0D7: ???
 ==25684==    by 0x5EEDF1C: ???
 ==25684==    by 0x5EEE01D: ???
 ==25684==    by 0x5EE93C0: ???
 ==25684==    by 0x5EE72B0: ???
 ==25684==    by 0x4897712: purple_marshal_VOID__POINTER (signals.c:629)
 ==25684==    by 0x48972D4: purple_signal_emit_vargs (signals.c:482)
 ==25684==    by 0x4897166: purple_signal_emit (signals.c:434)
 ==25684==    by 0x48659E8: purple_conversation_new (conversation.c:381)
 ==25684==    by 0x48957EB: serv_got_im (server.c:630)
 ==25684==    by 0x6AC44FE: ???
 ==25684==    by 0x6AC3DA5: ???
 ==25684==    by 0x6ABEA82: ???
 ==25684==    by 0x6ABC3A6: ???
 ==25684==    by 0x6ABC5BC: ???
 ==25684==    by 0x48A0F09: recv_cb (sslconn.c:144)
 ==25684==    by 0x80AD7BE: pidgin_io_invoke (gtkeventloop.c:78)
 ==25684==    by 0x47D76FC: g_io_unix_dispatch (giounix.c:162)
 ==25684==    by 0x47A06F7: g_main_context_dispatch (gmain.c:2144)
 ==25684==    by 0x47A3DA2: g_main_context_iterate (gmain.c:2778)


 > But by far the largest leaks in that file are in fontconfig and pango.

 So I filed a bug about that at
 http://bugzilla.gnome.org/show_bug.cgi?id=573389 but it got closed INVALID
 because of the way fontconfig allocates memory, it produces a false
 positive from valgrind.  So that really leaves the above leak as the
 biggest offender.

 > I didn't go through the entire log because it was enormous but the above
 is what I saw in the bits I did go through as I looked around.

 There are quite a number of the above leaks.

 If using valgrind didn't make an application so damn slow (and thus
 painful to use) I'd use it to run pidgin until it did OOM to get a clearer
 picture.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/8498#comment:4>
Pidgin <http://pidgin.im>
Pidgin