GNOME Bugzilla – Bug 444444
mem leaks
Last modified: 2009-05-27 22:29:18 UTC
Observed with aisleriot from gnome-games: ==22350== 18,860 (17,216 direct, 1,644 indirect) bytes in 115 blocks are definitely lost in loss record 162 of 177 ==22350== at 0x4020396: malloc (vg_replace_malloc.c:149) ==22350== by 0x4AF31E5: g_malloc (gmem.c:131) ==22350== by 0x4B081EA: g_slice_alloc (gslice.c:803) ==22350== by 0x4B0D702: g_string_sized_new (gstring.c:377) ==22350== by 0x4B0D79D: g_string_new (gstring.c:409) ==22350== by 0x4A23D1B: rsvg_standard_element_start (rsvg-base.c:256) ==22350== by 0x4A24712: rsvg_start_element (rsvg-base.c:653) ==22350== by 0x41D4E0A: xmlParseStartTag (parser.c:7237) ==22350== by 0x41DCA5D: xmlParseChunk (parser.c:9865) ==22350== by 0x4A22B55: rsvg_handle_write_impl (rsvg-base.c:982) ==22350== by 0x4A08DEA: rsvg_handle_fill_with_data (rsvg-base-file-util.c:37) ==22350== by 0x4A08EB9: rsvg_handle_new_from_file (rsvg-base-file-util.c:99) ==22350== by 0x806234B: games_preimage_new_from_file (games-preimage.c:301) ==22350== 880 bytes in 2 blocks are possibly lost in loss record 126 of 177 ==22350== at 0x4020396: malloc (vg_replace_malloc.c:149) ==22350== by 0x4AF31E5: g_malloc (gmem.c:131) ==22350== by 0x4A1B0AD: _rsvg_node_init (rsvg-structure.c:91) ==22350== by 0x4A05358: rsvg_new_image (rsvg-image.c:546) ==22350== by 0x4A23FF4: rsvg_standard_element_start (rsvg-base.c:246) ==22350== by 0x4A24712: rsvg_start_element (rsvg-base.c:653) ==22350== by 0x41D4E0A: xmlParseStartTag (parser.c:7237) ==22350== by 0x41DCA5D: xmlParseChunk (parser.c:9865) ==22350== by 0x4A22B55: rsvg_handle_write_impl (rsvg-base.c:982) ==22350== by 0x4A08DEA: rsvg_handle_fill_with_data (rsvg-base-file-util.c:37) ==22350== by 0x4A08EB9: rsvg_handle_new_from_file (rsvg-base-file-util.c:99) ==22350== by 0x806234B: games_preimage_new_from_file (games-preimage.c:301)
Do you know which SVGs were causing this problem? It'd be helpful so that I could reproduce the problem. Thanks.
It's one of the aisleriot card theme SVGs from gnome-games/gnome-games-extra-data svn trunk. I can repro this with this test programme: http://www.gnome.org/~chpe/testcases/rsvg-test-0.c $ test bonded.svg dondorf.svg ornamental.svg paris.svg ==3197== 13,716 (12,528 direct, 1,188 indirect) bytes in 81 blocks are definitely lost in loss record 66 of 77 ==3197== at 0x4020396: malloc (vg_replace_malloc.c:149) ==3197== by 0x4620205: g_malloc (gmem.c:131) ==3197== by 0x46351FA: g_slice_alloc (gslice.c:803) ==3197== by 0x463A712: g_string_sized_new (gstring.c:377) ==3197== by 0x463A7AD: g_string_new (gstring.c:409) ==3197== by 0x455EC5B: rsvg_standard_element_start (rsvg-base.c:256) ==3197== by 0x455F652: rsvg_start_element (rsvg-base.c:653) ==3197== by 0x4B34E0A: xmlParseStartTag (parser.c:7237) ==3197== by 0x4B3CA5D: xmlParseChunk (parser.c:9865) ==3197== by 0x455DA95: rsvg_handle_write_impl (rsvg-base.c:982) ==3197== by 0x4543CFA: rsvg_handle_fill_with_data (rsvg-base-file-util.c:37) ==3197== by 0x4543DC9: rsvg_handle_new_from_file (rsvg-base-file-util.c:99) ==3197== by 0x804875C: do_file (test0.c:16) ==3197== by 0x804888D: main (test0.c:57) Weirdly, when feeding the files one by one to the test programme, I only see a different leak; maybe there's some memory corruption going on (although valgrind doesn't report any invalid reads)... $ test dondorf.svg (and same in bonded.svg): ==4136== 7,620 (6,960 direct, 660 indirect) bytes in 45 blocks are definitely lost in loss record 21 of 23 ==4136== at 0x4020396: malloc (vg_replace_malloc.c:149) ==4136== by 0x4620205: g_malloc (gmem.c:131) ==4136== by 0x46351FA: g_slice_alloc (gslice.c:803) ==4136== by 0x45FA3A8: g_ptr_array_sized_new (garray.c:372) ==4136== by 0x45FA3FD: g_ptr_array_new (garray.c:366) ==4136== by 0x4555FDE: _rsvg_node_init (rsvg-structure.c:90) ==4136== by 0x4540268: rsvg_new_image (rsvg-image.c:546) ==4136== by 0x455EF34: rsvg_standard_element_start (rsvg-base.c:246) ==4136== by 0x455F652: rsvg_start_element (rsvg-base.c:653) ==4136== by 0x4B34E0A: xmlParseStartTag (parser.c:7237) ==4136== by 0x4B3CA5D: xmlParseChunk (parser.c:9865) ==4136== by 0x455DA95: rsvg_handle_write_impl (rsvg-base.c:982) ==4136== by 0x4543CFA: rsvg_handle_fill_with_data (rsvg-base-file-util.c:37) ==4136== by 0x4543DC9: rsvg_handle_new_from_file (rsvg-base-file-util.c:99) ==4136== by 0x804875C: do_file (test0.c:16) ==4136== by 0x804888D: main (test0.c:57)
g_slice_free can hold onto its memory, so it's possible that's what you're seeing. Please re-try with the following environment variable set: G_SLICE=always-malloc
I was already using always-malloc.
Using the current version of dondorf.svg from gnome-games-extra-data svn trunk (http://svn.gnome.org/viewvc/gnome-games-extra-data/trunk/cards/dondorf.svg?revision=38&view=markup) and librsvg svn trunk (2008-09-01) along with rsvg-view, I can reproduce the first leak (g_string_new; patch about to be attached) but not the second (_rsvg_node_init). Can anyone else?
Created attachment 117772 [details] [review] Use internal free function rather than g_free inside rsvg_node_image_free By using _rsvg_node_free rather than g_free to free the RsvgNode structure we can make sure the allocated 'type' field gets freed properly in rsvg_node_image_free (plus it's the right thing to do if more fields get added to RsvgNode in the future).
Created attachment 118882 [details] [review] Revised version of the patch, fixing double-free error. While investigating Bug 552517, I found a problem with this patch, resulting in a double-free error. Setting z->super.state to NULL after freeing it fixes this, and so here's an updated version of the patch.
It seems that I was mistakenly given credit for this patch: http://git.gnome.org/cgit/librsvg/commit/?id=6dd5969b1f353d3dbb3bee966513ae3436656827 I don't know if we can fix the git commit author but the changelog at least should credit Tom instead of me