Created attachment 6931 [details] Problematic PDF Command: gs -dNumRenderingThreads=1 -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -dAlignToPixels=0 -dGridFitTT=0 -dFirstPage=11 -dLastPage=11 -dUseCropBox -r250 -sOutputFile=out.png in.pdf Expected result: Page 11 should be converted to a PNG file within a *reasonable* time. Actual result: It takes forever to convert the PDF->PNG - it *will* do the conversion at some point, though. I was looking at out.png while gs was running and it seems that gs is writing nothing, or null, to the file since the last modified timestamp of the file gets updated every now and then but the file has a length of zero.
For me, the output is: GPL Ghostscript 9.00 (2010-09-14) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 11 through 11. Page 11 Loading NimbusSanL-Regu font from %rom%Resource/Font/NimbusSanL-Regu... 3685228 2255212 3142784 1716788 3 done. --This is where it will hang for a LONG time but eventually finish at some point.
When I ran this test case gs rev 11907 segfaulted on me and running valgrind produced a series of read errors. Assisted by the helpful Robin I managed to track down the problem: in clist_teardown_render_threads() it is not possible to retrieve the locking allocator from a threads memory chunk allocator once that chunk allocator has been released. A patch is attached which may explain it better.
Created attachment 6942 [details] Potential fix. The attached patch fixes the segfault and the valgrind errors for me.
I cluster tested this patch earlier and found that it caused various SEGVs. It turns out that this was my fault for misapplying the patch - the patch as given here works perfectly. Having retested the corrected version, it solves the problem and runs cleanly on the cluster. I've committed it as revision 11911. Apologies to Sebastian for suggesting his patch wasn't right in the svn logs!