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 770070 - [PATCH] Fix memory leak in EvSidebarThumbnails
[PATCH] Fix memory leak in EvSidebarThumbnails
Status: RESOLVED FIXED
Product: evince
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-08-18 07:15 UTC by Eric R. Schulz
Modified: 2016-09-04 09:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix memory leak in EvSidebarThumbnails (1.37 KB, patch)
2016-08-18 07:15 UTC, Eric R. Schulz
none Details | Review
Fix memory leak in ev_sidebar_thumbnails_document_changed_cb() (1.39 KB, patch)
2016-09-03 15:57 UTC, Eric R. Schulz
committed Details | Review

Description Eric R. Schulz 2016-08-18 07:15:55 UTC
Created attachment 333546 [details] [review]
Fix memory leak in EvSidebarThumbnails

GtkListStore keeps a reference to the stored object, so it must be cleared before calling g_hash_table_destroy().

Valgrind:
==21719== 54,344 (88 direct, 54,256 indirect) bytes in 1 blocks are definitely lost in loss record 15,414 of 15,429
==21719==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21719==    by 0x73136A8: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==21719==    by 0x732A8B2: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==21719==    by 0x72FC6CD: g_hash_table_new_full (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==21719==    by 0x44E96A: ev_sidebar_thumbnails_document_changed_cb (ev-sidebar-thumbnails.c:985)
==21719==    by 0x7080FA4: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.0)
==21719==    by 0x7092FC0: signal_emit_unlocked_R (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.0)
==21719==    by 0x709BD5B: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.0)
==21719==    by 0x709C08E: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.0)
==21719==    by 0x70854D3: g_object_dispatch_properties_changed (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.0)
==21719==    by 0x7087960: g_object_notify (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.0)
==21719==    by 0x50908B0: ev_document_model_set_document (ev-document-model.c:381)
Comment 1 Carlos Garcia Campos 2016-09-03 06:11:02 UTC
I don't understand this. If the hash table have one reference and the model another, the order in which they are destroyed shouldn't matter to release their references.

I think that what we are leaking is the whole hash table if ev_sidebar_thumbnails_document_changed_cb is called twice. We should probably check there if we already have a hash table and clear it.
Comment 2 Eric R. Schulz 2016-09-03 15:57:58 UTC
Created attachment 334727 [details] [review]
Fix memory leak in ev_sidebar_thumbnails_document_changed_cb()

Clear the loading icon hash table if it already exists.
Comment 3 Carlos Garcia Campos 2016-09-04 09:02:54 UTC
Comment on attachment 334727 [details] [review]
Fix memory leak in ev_sidebar_thumbnails_document_changed_cb()

Pushed, thanks!