Note that this is a high priority bug for embedded customers since progressive leaks will consume the printer's memory, requiring a reset. While the chunk memory manager used when multi-threaded rendering is enabled recovers the leaked RAM, the clist and graphics library should not rely on the memory manager (or garbage collection) to recover from leaks. Running the mtrender branch (rev 8700) DEBUG build prints out leaks for several of the 'comparefiles' test cases. The list of files that leak in various ways are: 1_2001.pdf 32004755.pdf Altona.Page_3.2002-09-27.pdf Altona_Technical_1v1_x3.pdf Bug687840.pdf Bug689083.pdf Bug689189.pdf H00216q.pdf Openhuis_pdf_zw.pdf PixelisAd.pdf QuickNews_Nov22.pdf S2_Digitalproof-Forum_x3k.pdf S_6_7.pdf TestMap.pdf adesso2.pdf brochurep1.pdf bug_687457.pdf dave.pdf file.pdf file2.pdf pro.pdf ngnews.pdf ngnews1.pdf xngnews.pdf 148-11.ps Bug687396.ps Bug687603.ps Bug688308.ps japan.ps korea.ps I will attach the complete log of the leaks. The command line used to test this was: gswin32c -q -Z: -r300 -sDEVICE=ppmraw -o nul -dLastPage=1 -dJOBSERVER
Created attachment 3985 [details] comparefile_leaks.zip Correction to the command line used (I forgot -dNumRenderingThreads=2) gswin32c -q -Z: -r300 -sDEVICE=ppmraw -o nul -dLastPage=1 -dJOBSERVER -dNumRenderingThreads=2
Note that -dNumRenderingThreads=1 is adequate to track the leaks and is easier to debug since there is only a single instance of the 'chunk' memory wrapper, so breakpoints are less confusing. The 'sequence' value is useful for setting conditional breakpoints. Run once to get the sequence numbers of the allocation that was leaked, then set conditional breakpoints in chunk_obj_alloc around line 351 (after cmem is set) for the value matching cmem->sequence_counter.
Created attachment 4248 [details] patch.txt A suggested patch is being tested.
The local testing finished with no problems except ones registered in other bugs.
Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2008-August/008506.html
The Comment #5 fix has been unwond (except a minor improvement in debug printing) with the patch http://ghostscript.com/pipermail/gs-cvs/2008-August/008517.html Reopening the bug and passing it to Ralph who owns color spaces.
Please not that I have got plans to serialise other color spaces to clist and use them while rendering shadings during clist interpretation in order to minimize the size of clist. Due to that the problem is not restricted with Indexed.
s/Please not/Please note
Reassigning. This appears not to have been ever properly addressed, and an attempted patch was reverted resulting in a duplicate report (690313).
*** Bug 690313 has been marked as a duplicate of this bug. ***
I have a local version of the allocator that uses the non-relocating 'chunk' memory wrapper, so it should now be relatively easy to locate the cause. I had already determined that the table data wasn't getting freed where I think it should be (as a result of reference counting of the colorspace).
Enabling the freeing of the table (palette) in gscolor2.c exposes a problem in the management of XL's palette.
This should be partially fixed, reassigning back to ray for followup on Comment #11.
The multi-threaded renderer "cleans up" the leaking items, so it is sort of a work around (or using a 'chunk' wrapper during clist rendering even if not multi-threaded)
Re-testing with HEAD (rev 9862) shows that the leaks are gone, so probably the freeing of the palette that Henry mentioned in comments 12 and 13 were the cause. Closing as fixed.
Changing customer bugs that have been resolved more than a year ago to closed.