After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 627853 - Memory leak in em_format_push_level()
Memory leak in em_format_push_level()
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.32.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks: 627707
 
 
Reported: 2010-08-24 17:07 UTC by David Woodhouse
Modified: 2013-09-13 01:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description David Woodhouse 2010-08-24 17:07:31 UTC 
==16968== 24 bytes in 1 blocks are definitely lost in loss record 7,207 of 22,411
==16968==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==16968==    by 0x3A4DC45784: g_malloc (in /lib64/libglib-2.0.so.0.2512.0)
==16968==    by 0x3A4DC5A8B9: g_slice_alloc (in /lib64/libglib-2.0.so.0.2512.0)
==16968==    by 0x3A4DC5ABC5: g_slice_alloc0 (in /lib64/libglib-2.0.so.0.2512.0)
==16968==    by 0xFE4A6D4: em_format_push_level (em-format.c:635)
==16968==    by 0xFE4C56C: emf_format_clone (em-format.c:165)
==16968==    by 0xF15D732: efh_format_timeout (em-format-html.c:327)
==16968==    by 0xF13ACCA: mail_reader_set_folder (e-mail-reader.c:2488)
==16968==    by 0xF13A884: action_mail_show_source_cb (e-mail-reader.c:1323)
==16968==    by 0x3A4E40D7BD: g_closure_invoke (in /lib64/libgobject-2.0.so.0.2512.0)
==16968==    by 0x3A4E425D68: ??? (in /lib64/libgobject-2.0.so.0.2512.0)
==16968==    by 0x3A4E4274C5: g_signal_emit_valist (in /lib64/libgobject-2.0.so.0.2512.0)
==16968== 
==16968== 24 bytes in 1 blocks are definitely lost in loss record 7,208 of 22,411
==16968==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==16968==    by 0x3A4DC45784: g_malloc (in /lib64/libglib-2.0.so.0.2512.0)
==16968==    by 0x3A4DC5A8B9: g_slice_alloc (in /lib64/libglib-2.0.so.0.2512.0)
==16968==    by 0x3A4DC5ABC5: g_slice_alloc0 (in /lib64/libglib-2.0.so.0.2512.0)
==16968==    by 0xFE4A6D4: em_format_push_level (em-format.c:635)
==16968==    by 0xFE4C56C: emf_format_clone (em-format.c:165)
==16968==    by 0xF15D732: efh_format_timeout (em-format-html.c:327)
==16968==    by 0xF137ECF: mail_reader_message_selected_timeout_cb (e-mail-reader.c:2353)
==16968==    by 0xF139E37: mail_reader_message_selected_cb (e-mail-reader.c:2405)
==16968==    by 0x3A4E40D7BD: g_closure_invoke (in /lib64/libgobject-2.0.so.0.2512.0)
==16968==    by 0x3A4E425D68: ??? (in /lib64/libgobject-2.0.so.0.2512.0)
==16968==    by 0x3A4E4274C5: g_signal_emit_valist (in /lib64/libgobject-2.0.so.0.2512.0)
==16968==
Comment 1 David Woodhouse 2010-08-24 17:13:28 UTC 
Why does em_format_clear_puri_tree() call em_format_push_level() which adds a *new* node? And how is that ever supposed to get freed?
Comment 2 Matthew Barnes 2010-08-27 14:34:31 UTC 
(In reply to comment #1)
> Why does em_format_clear_puri_tree() call em_format_push_level() which adds a
> *new* node? And how is that ever supposed to get freed?

I think what it's doing is destroying the current pending URI tree and calling em_format_push_level() to install a new root node, which is fine for -resetting- the tree.  But it looks like finalize() never frees that root node.

Also, in emf_clear_puri_tree() I empty out the GQueue but never freed the GQueue itself.  A GQueue is just two pointers and an unsigned int, so there's your 24 lost bytes on a 64-bit system.
Comment 3 Matthew Barnes 2010-08-27 14:50:21 UTC 
This should do it.  Fixed for 2.31.91 in:
http://git.gnome.org/browse/evolution/commit/?id=9cbc19e94931c69e93e0e8e3847d017568bd0979