Bug 689822 - Memory leaks during rendering clist.
Summary: Memory leaks during rendering clist.
Status: NOTIFIED FIXED
Alias: None
Product: GhostPCL
Classification: Unclassified
Component: PCL interpreter (show other bugs)
Version: master
Hardware: All All
: P2 normal
Assignee: Ray Johnston
URL:
Keywords:
: 690313 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-05-05 09:41 UTC by Ray Johnston
Modified: 2011-09-18 21:47 UTC (History)
1 user (show)

See Also:
Customer: 951, 661
Word Size: ---


Attachments
comparefile_leaks.zip (14.71 KB, application/octet-stream)
2008-05-05 09:44 UTC, Ray Johnston
Details
patch.txt (1.52 KB, patch)
2008-07-29 10:00 UTC, leonardo
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ray Johnston 2008-05-05 09:41:42 UTC
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
Comment 1 Ray Johnston 2008-05-05 09:44:16 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
Comment 2 Ray Johnston 2008-05-05 09:49:08 UTC
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.
Comment 3 leonardo 2008-07-29 10:00:03 UTC
Created attachment 4248 [details]
patch.txt

A suggested patch is being tested.
Comment 4 leonardo 2008-07-29 13:02:36 UTC
The local testing finished with no problems except ones registered in other 
bugs.
Comment 5 leonardo 2008-08-03 05:29:21 UTC
Patch to HEAD :
http://ghostscript.com/pipermail/gs-cvs/2008-August/008506.html
Comment 6 leonardo 2008-08-05 23:31:29 UTC
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.
Comment 7 leonardo 2008-08-05 23:37:37 UTC
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.
Comment 8 leonardo 2008-08-05 23:38:16 UTC
s/Please not/Please note
Comment 9 Ray Johnston 2009-03-11 23:09:16 UTC
Reassigning. This appears not to have been ever properly addressed, and an
attempted patch was reverted resulting in a duplicate report (690313).
Comment 10 Ray Johnston 2009-03-11 23:09:48 UTC
*** Bug 690313 has been marked as a duplicate of this bug. ***
Comment 11 Ray Johnston 2009-03-11 23:12:54 UTC
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).
Comment 12 Henry Stiles 2009-03-16 08:59:19 UTC
Enabling the freeing of the table (palette) in gscolor2.c exposes a problem in
the management of XL's palette.
Comment 13 Henry Stiles 2009-03-18 19:02:54 UTC
This should be partially fixed, reassigning back to ray for followup on Comment #11.
Comment 14 Ray Johnston 2009-06-16 09:36:42 UTC
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)
Comment 15 Ray Johnston 2009-07-21 10:38:17 UTC
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.
Comment 16 Marcos H. Woehrmann 2011-09-18 21:47:05 UTC
Changing customer bugs that have been resolved more than a year ago to closed.