Bug 432926 - gs gets stuck in the garbage collector when interpreting certain files
Summary: gs gets stuck in the garbage collector when interpreting certain files
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: ghostscript
Version: 4.6
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-02-15 07:35 UTC by Andrew Ryan
Modified: 2018-10-20 00:33 UTC (History)
3 users (show)

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.
Clone Of:
Environment:
Last Closed: 2009-05-18 20:03:34 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0949 0 normal SHIPPED_LIVE ghostscript bug fix update 2009-05-18 13:21:41 UTC

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


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