Comment 7 for bug 986271

Finally was able to work on inkscape on linux (Ubuntu 12.04LTS) where the tools are better. The attached patch fixes the core issue with the memory leak (for all image saves, not just EMF). The free() which was placed in the emf-win32-print.cpp should be removed when this patch goes in.

As a side note, even with this patch, the virtual memory still rises on each EMF save that includes images, just not as much.
With valgrind I could not determine, beyond the leak plugged with the above patch, exactly where this was happening. Most frustrating. To use valgrind at all it was necessary to add to default.supp:

{
   <wcslen1>
   Memcheck:Addr8
   fun:__wcslen_sse2
   fun:wcscoll
}

{
   <wcslen2>
   Memcheck:Cond
   fun:__wcslen_sse2
   fun:wcscoll
}
{
   <iffyinflate>
   Memcheck:Cond
   fun:inflateReset2
   fun:inflateInit2_
   obj:*
}

(To eliminate a zillion warnings on wslen_sse3). Run like this:

 export _INKSCAPE_GC=disable
 valgrind --leak-check=full --num-callers=50 src/inkscape >/tmp/foo 2>&1

It was incredibly, painfully, slow. Minutes to open a window. Anyway, open an SVG with some images, save it as EMF (with images) twice, exit. This produced an output file with 23000 loss records, 400K lines and 43MB in size and ending with:

==9760== LEAK SUMMARY:
==9760== definitely lost: 251,061 bytes in 8,668 blocks
==9760== indirectly lost: 1,686,567 bytes in 27,444 blocks
==9760== possibly lost: 31,758,052 bytes in 262,250 blocks
==9760== still reachable: 12,257,891 bytes in 23,151 blocks
==9760== suppressed: 0 bytes in 0 blocks

The problem being that the memory leaks associated with image operations seem to be in the "possibly lost" and "still reachable" categories. (It also doesn't help that the call stack has been observed as being up to 65 levels deep in gdb - sometimes there may be such a thing as too much abstraction!)