Bug 432926

Summary: gs gets stuck in the garbage collector when interpreting certain files
Product: Red Hat Enterprise Linux 4 Reporter: Andrew Ryan <aryan>
Component: ghostscriptAssignee: Tim Waugh <twaugh>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 4.6CC: llim, pknirsch, tao
Target Milestone: rcKeywords: Patch
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
* Ghostscript could become stuck in a loop while running its garbage collector. Ghostscript would partially render a file, then stop with ghostscript consuming 100% of CPU time. The version of Ghostscript provided with this advisory includes a patch from upstream that makes the memory manager scan all chunks for available free space, where previously it scanned only the currently open chunk. This patch improves Ghostscript's memory utilization and avoids the possibility of the garbage collector becoming stuck in a loop.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-18 20:03:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch backported to ghostscript-7.07-33 none

Description David Robinson 2008-02-15 07:35:17 UTC 
Description of problem:
The gs garbage collector gets stuck (consumes 100% CPU time) when gs interprets
certain files. This causes problems when those files are printed (because gs is
used by CUPS).

Version-Release number of selected component (if applicable):
RHEL 4.6
ghostscript-7.07-33

How reproducible:
100%

Steps to Reproduce:
1. gs -sDEVICE=x11alpha test.ps
  
Actual results:
The file is partially rendered, then gs consumes 100% CPU time.

Expected results:
File renders correctly and completely.

Additional info:
RHEL 5 does not have this problem; ghostscript-8.15.2-9.1.el5 does not present
this problem with this particular PS file. 

A workaround exists by using the -dNOGC option:

this fails:
# gs -sDEVICE=x11alpha test.ps
but this works correctly:
# gs -sDEVICE=x11alpha -dNOGC test.ps

At first glance the problem appears to be this upstream bug:
http://bugs.ghostscript.com/show_bug.cgi?id=421057

However simply applying the patch for 421057 does not solve the problem
(although setting DEFAULT_VM_THRESHOLD_SMALL and DEFAULT_VM_THRESHOLD_LARGE (in
src/zvmem2.c:27) to 1000000 and 8000000 respectively does allow the file to render).

The problem is fixed by the upstream patch at the link below:
http://cvs.ghostscript.com/cgi-bin/viewcvs.cgi/ghostscript?rev=2259&view=rev

To quote the commit message:
"Fix: Makes the standard memory manager scan all chunks, not just the
currently open one, for available free space.  This is a long-planned,
long-overdue improvement that can improve memory utilization dramatically."

A patch that corrects the problem is attached (its backported from upstream).
Comment 1 David Robinson 2008-02-15 07:35:18 UTC 
Created attachment 294992 [details]
patch backported to ghostscript-7.07-33
Comment 4 RHEL Program Management 2008-09-05 17:12:44 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 8 Ruediger Landmann 2009-01-14 06:47:17 UTC 
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
* Ghostscript could become stuck in a loop while running its garbage
collector. Ghostscript would partially render a file, then stop with ghostscript consuming 100% of CPU time. The version of Ghostscript provided with this advisory includes a patch from upstream that makes the memory manager scan all chunks for available free space, where previously it scanned only the currently open chunk. This patch improves Ghostscript's memory utilization and avoids the possibility of the garbage collector becoming stuck in a loop.
Comment 9 errata-xmlrpc 2009-05-18 20:03:34 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0949.html