Summary: | Memory leaks during rendering clist. | ||
---|---|---|---|
Product: | GhostPCL | Reporter: | Ray Johnston <ray.johnston> |
Component: | PCL interpreter | Assignee: | Ray Johnston <ray.johnston> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | CC: | henry.stiles |
Priority: | P2 | ||
Version: | master | ||
Hardware: | All | ||
OS: | All | ||
Customer: | 951, 661 | Word Size: | --- |
Attachments: |
comparefile_leaks.zip
patch.txt |
Description
Ray Johnston
2008-05-05 09:41:42 UTC
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. |