[gs-bugs] [Bug 690346] many pcl files from the customer test file directory have problems.

bugs.ghostscript.com-bugzilla-daemon at ghostscript.com bugs.ghostscript.com-bugzilla-daemon at ghostscript.com
Mon Mar 23 22:57:07 PDT 2009


ray.johnston at artifex.com changed:

           What    |Removed                     |Added
         AssignedTo|ray.johnston at artifex.com    |ralph.giles at artifex.com

------- Additional Comments From ray.johnston at artifex.com  2009-03-23 22:57 -------
I've traced the 'ialloc' functions (base/gsalloc.c) and the problem appears to
be systemic. This allocator is just not very good at recovering freed blocks
and only performs 'annealing' (chunk_consolidate_free) lazily, and after the
free space has been fragmented.

The ialloc memory allocates 30 20,000 byte chunks PER BAND, while the chunk
allocator allocates ZERO chunks. The pattern of allocations and frees, and the
particular (lazy) allocation method used in the ialloc manager seem to be
severely impacted by this file. There are 543 images in the first band,
and the image allocations and the color space switching all add up to a
sequence that confuses this allocator.

Note that I enabled CONSOLIDATE_BEFORE_ADDING_CHUNK in base/gsalloc.c and 
encountered SEGFAULT problems. This code has at least one error that I fixed,
but since this code may not have ever been tested, I didn't work on it any

I will assign this over to Ralph to see if he wants to dig into the problems
in 'ialloc'. I think that the problem is not caused by the clist or other
code 'leaking' during the rendering.

Sorry, Ralph.

I am available to discuss this and can provide logs if desired.

I will apply some of the tricks I've seen in tracing through the ialloc
manager to see if I can speed up the chunk allocator (without causing the
problems seen with this file).

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

More information about the gs-bugs mailing list