Bug 690902

Summary: segmentation fault in version 8.70, warning in 8.62
Product: Ghostscript Reporter: Antonio Macchi <antonio_macchi>
Component: PDF WriterAssignee: Alex Cherepanov <alex>
Status: RESOLVED FIXED    
Severity: normal CC: alex, jackie.rosen
Priority: P4    
Version: 8.70   
Hardware: PC   
OS: Linux   
Customer: Word Size: ---
Attachments: ps_log.zip

Description Antonio Macchi 2009-11-09 19:58:58 UTC 
I have a file that noone pdfeditor (evince nor kpdf) can read...

only ghostview...
so I want to "rewrite" that file in a good form

$ gs -dBATCH -dNOPAUSE -dQUIET -sDEVICE=pdfwrite
-sOutputFile=FATTURA.bis.pdf FATTURA.pdf 

using gs version 8.62 creates this output

*** Warning:  An error occurred while reading an XREF table.
   **** The file has been damaged.  This may have been caused
   **** by a problem while converting or transfering the file.
   **** Ghostscript will attempt to recover the data.
   **** Warning: stream operator not terminated by valid EOL.
   **** Warning: stream operator not terminated by valid EOL.
   **** Warning: stream operator not terminated by valid EOL.
   **** Warning: stream operator not terminated by valid EOL.
   **** Warning: stream operator not terminated by valid EOL.
   **** Warning: stream operator not terminated by valid EOL.
   **** Warning: stream operator not terminated by valid EOL.
   **** Warning: stream operator not terminated by valid EOL.
   **** Warning: stream operator not terminated by valid EOL.

   **** This file had errors that were repaired or ignored.
   **** The file was produced by:
   **** >>>> GLS-Italy <<<<
   **** Please notify the author of the software that produced this
   **** file that it does not conform to Adobe's published PDF
   **** specification.


and then it creates a new well formatted pdf file, visibile on every editor

----------------------------------------------------------------

but... using the last version, 8.70

**** Warning:  An error occurred while reading an XREF table.
   **** The file has been damaged.  This may have been caused
   **** by a problem while converting or transfering the file.
   **** Ghostscript will attempt to recover the data.
Segmentation fault 

and no file will be created

so, imho, the first behavior is better.
thanks and bye
Comment 1 Marcos H. Woehrmann 2009-11-09 20:33:38 UTC 
I agree the previous behaviour was better; please attach a copy of FATTURA.pdf
and we'll see what we can do.
Comment 2 Marcos H. Woehrmann 2009-11-09 22:15:20 UTC 
Created attachment 5648 [details]
FATTURA.pdf
Comment 3 Marcos H. Woehrmann 2009-11-09 22:16:57 UTC 
search-svn-revs shows that this broke in r8962:

r8962 | ken | 2008-08-11 07:16:18 -0700 (Mon, 11 Aug 2008) | 10 lines

Move the interpretation of PostScript (and PDF) color spaces from PostScript
into C.
Comment 4 Ken Sharp 2009-11-10 01:23:48 UTC 
Although it was my (large) change for PS colour that exposed this problem, I'm
not sure its actually my fault. The last call into the colour code is
considerably before the actual point of error, which occurs trying to 'exec' a
chunk of unavailable memory. Also there are no colour spaces in the file likely
to cause a problem (simple device spaces throughout).

I think the problem is more to do with trying to fix a broken PDF file which
just happened to work before, and just happens not to work after (notice the
numerous 'stream operator not terminated by valid EOL' messages)

I'm trying to narrow the problem down to see where it actually lies, this will
probably take some time.
Comment 5 Ken Sharp 2009-11-10 03:04:59 UTC 
Created attachment 5649 [details]
ps_log.zip

OK, I don't think this is me, I think its something to do with the PDF
interpreter, but I don't know what. The PostScript interpreter seems to be
reading lines from a file (the input file possibly) and executing them, in a
loop I think.

I'm going to CC Alex in to solicit his opinion, I've attached the log of
PostScript operations executed in case that's helpful. The crash occurs after
the final exec.
Comment 6 Ken Sharp 2009-11-10 03:05:41 UTC 
CC'ing Alex. Alex please have a look at this problem and tell me what you think
is wrong.
Comment 7 Alex Cherepanov 2009-11-10 06:29:44 UTC 
There's something wrong with scanning of big names. I'm taking over.
Comment 8 Alex Cherepanov 2009-11-11 05:55:26 UTC 
Increase the size of the initial buffer in the scanner dynamic area to accept
the string of maximum valid size. Protect the buffer from overflow when the
scanner state is saved during reading of a name that exceed max name length.

The following patch has been committed as a rev. 10312.
http://ghostscript.com/pipermail/gs-cvs/2009-November/010038.html
Regression testing shows no differences.