[gs-bugs] [Bug 692352] GS PDF conversion eats up and corrupts memory

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Fri Jul 29 12:04:56 UTC 2011


http://bugs.ghostscript.com/show_bug.cgi?id=692352

Robin Watts <robin.watts at artifex.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |robin.watts at artifex.com

--- Comment #6 from Robin Watts <robin.watts at artifex.com> 2011-07-29 12:04:54 UTC ---
I spent some time looking into this yesterday, and my conclusions match those
of Alex. It's not the shading algorithm itself that leaks, but something in the
reference handling of the postscript operators involved.

With the following command:

gs/debugbin/gswin32c.exe -dMaxBitmap=100000000 -P -r72 -sDEVICE=pkmraw -o ne
w.pkm ../ghostpcl/tests_private/comparefiles/Bug689189.pdf

with alexes patch inserted and memento enabled, I find that:

 * A 'save' operator causes a new chunk to be created (allocation event
153212).

 * Shortly afterwards we hit idict.c:dict_create_contents:196 and allocate a
ref array, that returns with address 0xb569a8 (for me).

 * At allocation event 153222, we pull the ripcord and the whole chunk is freed
(on a restore).

 * Shortly thereafter we do a VMreclaim, and in the middle of the ref marking
phase, between allocation events 155751 and 155752 we write to 0xb569a9.

My reading of this is that somehow a pointer is being kept in gc memory to
something that should have been cleaned up when the restore happened. But I am
having no luck tracking this down, so returning it to Alex for him to consider.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list