Bug 432926 - gs gets stuck in the garbage collector when interpreting certain files
gs gets stuck in the garbage collector when interpreting certain files
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: ghostscript (Show other bugs)
4.6
All Linux
high Severity high
: rc
: ---
Assigned To: Tim Waugh
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-15 02:35 EST by Andrew Ryan
Modified: 2010-10-22 18:31 EDT (History)
3 users (show)

See Also:
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 16:03:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch backported to ghostscript-7.07-33 (5.18 KB, patch)
2008-02-15 02:35 EST, David Robinson
no flags Details | Diff

  None (edit)
Description David Robinson 2008-02-15 02:35:17 EST
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 02:35:18 EST
Created attachment 294992 [details]
patch backported to ghostscript-7.07-33
Comment 4 RHEL Product and Program Management 2008-09-05 13:12:44 EDT
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 01:47:17 EST
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 16:03:34 EDT
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

Note You need to log in before you can comment on or make changes to this bug.