ghostscript crashes when processing attached file (created by ghostscript itself). The behavior does not seem to be driver dependent - it does the same if I use tiffgray driver. gswin32c -sDEVICE=jpeg -sOutputFile=c:\temp\gray.jpg -r300 -sPAPERSIZE=letter -dBATCH -dSAFER 04.pdf AFPL Ghostscript 8.53 (2005-10-20) Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 4. Page 1 Loading NimbusMonL-Regu font from C:\Program Files\ghostscript\fonts/n022003l.pf b... 2328496 909370 3124880 1704999 3 done. >>showpage, press <return> to continue<< Page 2 >>showpage, press <return> to continue<< Page 3 --- at this moment windows messagebox pops up: Microsoft Visual C++ Runtime Library (x) Assertion Failed! Program:...\gs8.53\bin\gswin32c.exe File: .\src\gxccman.c Line: 567 Expression: cc->pair == pair
Created attachment 1835 [details] input pdf file
xpdf works fine, gs linux x86 x11 also crashes at page 3. Page 1 Loading NimbusMonL-Regu font from /usr/share/ghostscript/fonts/n022003l.pfb... 2602288 1025454 3085240 1646748 3 done. >>showpage, press <return> to continue<< Page 2 >>showpage, press <return> to continue<< Page 3 gs: src/gxccman.c:567: gx_add_cached_char: Assertion `cc->pair == pair' failed. Abort with -dDEBUG, here it where it fails (the %%EOF is strange!!!): ========== %Resolving: [3256 0] %Resolving: [115 0] %Resolving: [11 0] %Function: << /Length 47 /FunctionType 4 /Domain [0 1] /File -file- /Filter /FlateDecode /FilePosition 3398982 /Function {--dup-- 0.311 --mul-- 1 --exch-- --sub-- --exch-- --dup-- 0.908 --mul-- 1 --exch-- --sub-- --exch-- 0.904 --mul-- 1 --exch-- --sub--} /Range [0 1 0 1 0 1] >> 1 scn q 4.16667 0 0 4.16667 0 0 cm BT /R2982 9 Tf %Resolving: [3258 0] %Resolving: [2982 0] 1 0 0 1 409.748 690.477 Tm [ (C) 25.0033 (orporate ) -24.9935 (Office:) ] TJ resmp FindResource beg DefaultRGB resmp FindResource end resmp FindResource beg DefaultRGB resmp FindResource end %Resolving: [3036 0] 0.605 0 -0.35 -0.266 1.438 1.075 d1 q 4.16667 0 0 4.16667 0 0 cm BT /R48 0.24 Tf %Resolving: [3258 0] %Resolving: [48 0] 1 0 0 1 0 0 Tm (C) Tj ET Q %%EOF gs: src/gxccman.c:567: gx_add_cached_char: Assertion `cc->pair == pair' failed. Abort ====================
Hmm, when I run it on my system, it fails with same error but processing another font instance 3186 0 obj. Isn't it deterministic ? Also penum->cc->pair->font at the failure point points to a Type 1 font than penum->orig_font does. The latter points to a Type 3 font. They must point to same font. Maybe penum->cc->pair wasn't correctly relocated by garbager ? Or gs_show_enum instances have been erroneusly interchanged two between different invocations of 'show' (one in a main text, and another one in a charproc) ?
gx_add_fm_pair release a fm pair while processing penum 4350. But at this moment the enum 4349 (corresponds to a Type 3 font) is still active (exists on estack) and points to same fm pair.
Patches to HEAD : http://ghostscript.com/pipermail/gs-cvs/2005-December/005832.html http://ghostscript.com/pipermail/gs-cvs/2005-December/005833.html http://ghostscript.com/pipermail/gs-cvs/2005-December/005834.html
Thanks, Leonardo!!! You are my hero!
*** Bug 688520 has been marked as a duplicate of this bug. ***