Re: [NTG-pdftex] another problem -- of pdftex or gs?

...

...

...

...

"Thanh" == Thanh Han The writes:

Hi, the following file caused gs to segfault:

http://www.sendspace.com/file/ol6tlx

The command I used is: ,-------- | gs -dNOPAUSE -sDEVICE=nullpage -sOutputFile=/dev/null -dBATCH survey-vn.ps `--------

and gs -v gave:

,-------- | GPL Ghostscript 8.01 (2004-01-30) | Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved. `--------

The ps file was converted by pdftops from survey-vn.pdf, the vietnamese translation of the free math font survey by Stephen G. Hartke, compiled by pdftex. The pdf itself and the ps converted by acroread didn't cause the problem with the above command. Another thing to notice is that the problem doesn't occur with other devices, for example gv showed the file quite normally, and the device ppm also works fine.

Maybe some PS guru here (eg Reinhard) can figure out what is wrong with the ps file?

I'm not sure that there is something wrong with the ps file and I'm not able to reproduce this with gs-8.01. However, there are problems with other versions. Some versions hang, so I had to limit CPU time in order to ba able to check with all versions I have installed. $ for v in `gs --versions`;do (ulimit -t 10;GS=$v gs -dNOPAUSE -sDEVICE=nullpage -sOutputFile=/dev/null -dBATCH survey-vn.ps 2>&1 ; echo "exit status=$?");done | sed -e /^Copyright/d -e /^This/d GNU Ghostscript 6.52 (2001-10-20) exit status=0 GNU Ghostscript 6.53 (2002-02-13) exit status=0 AFPL Ghostscript 7.03 (2001-10-20) exit status=0 AFPL Ghostscript 7.04 (2002-01-31) exit status=0 GNU Ghostscript 7.05 (2002-04-22) exit status=0 GNU Ghostscript 7.06 (2003-04-01) exit status=0 GNU Ghostscript 7.07 (2003-05-17) exit status=0 AFPL Ghostscript DEVELOPMENT RELEASE 7.20 (2002-04-03) exit status=139 AFPL Ghostscript DEVELOPMENT RELEASE 7.22 (2002-08-06) exit status=139 AFPL Ghostscript 8.00 (2002-11-21) exit status=0 GPL Ghostscript 8.01 (2004-01-30) exit status=0 AFPL Ghostscript BETA RELEASE 8.10 (2003-05-21) exit status=0 AFPL Ghostscript 8.11 (2003-08-16) exit status=0 AFPL Ghostscript 8.12 (2003-12-08) exit status=137 AFPL Ghostscript 8.13 (2003-12-31) exit status=137 AFPL Ghostscript 8.14 (2004-02-20) exit status=137 GPL Ghostscript 8.15 (2004-09-22) exit status=137 AFPL Ghostscript BETA RELEASE 8.30 (2004-05-29) exit status=0 AFPL Ghostscript BETA RELEASE 8.31 (2004-08-28) exit status=0 AFPL Ghostscript BETA RELEASE 8.32 (2004-10-26) exit status=0 AFPL Ghostscript BETA RELEASE 8.33 (2004-11-20) exit status=0 AFPL Ghostscript 8.50 (2004-12-10) exit status=0 GPL Ghostscript 8.51 (2006-05-27) exit status=0 AFPL Ghostscript 8.53 (2005-10-20) exit status=0 GPL Ghostscript 8.54 (2006-05-17) $ Exit status 139 means that a segmentation fault occurred and 137 means that the process had been killed by the shell when the CPU-time limit of 10 seconds had been exceeded. Assume there is a bug in the ps file, how is it possible to display the file or convert it to other formats properly? Curiously you get different results depending on -dNOPAUSE and -dDEBUG. I tried with gs-7.22. gs -sDEVICE=nullpage -sOutputFile=/dev/null -dBATCH survey-vn.ps leads to a segmentation fault. Adding -dDEBUG and removing -dNOPAUSE tells me that the problem occurrs on page 15. $ gs -dDEBUG -sDEVICE=nullpage -sOutputFile=/dev/null -dBATCH survey-vn.ps [...] **** DSC comment: /Page << /DSC_struct -dsc_data_struct- /PageNum 15 >> **** DSC comment: /PageOrientation << /PageOrientation 0 /DSC_struct -dsc_data_struct- >> Segmentation fault $ But if I put -dNOPAUSE back again everything works: $ gs -dDEBUG -dNOPAUSE -sDEVICE=nullpage -sOutputFile=/dev/null -dBATCH survey-vn.ps [...] **** DSC comment: /Page << /DSC_struct -dsc_data_struct- /PageNum 24 >> **** DSC comment: /PageOrientation << /PageOrientation 0 /DSC_struct -dsc_data_struct- >> $ I suppose that gs is so buggy that it doesn't make sense to use it as a validator. Maybe you get another result too if you add -dDEBUG too. gs-8.01 is probably broken anyway. I remember that 8.00 had not even been able to process files created by dvips properly. In composed words containing a hyphen (quite common in German) gs added negative kern in front of the hyphen. Don't remember when it had been fixed but it is quite likely that 8.01 still contains this bug. Recently someone asked me for help. He found me when he searched Google for "/invalidfont". He was using gs-8.54, the latest GPL release, on Windows. He got an error message, at least, but gs-8.54 on Linux did not complain about his file but silently aborted with a segmentation fault. It worked properly for me with 8.51 and obviously he switched to this version too and is happy with it. Karl also said that he encountered many segmentation faults in 8.54. In my opinion gs is too unstable to rely on it. Probably the reason for this particular problem is that gs is quite large and new features are added while nobody has enough time to look into old stuff, and I suppose that the nullpage device is such old stuff. So, how can we validate a pdf file? Well, I think that xpdf is a first step. If pdftops doesn't complain we know that the pdf file is not completely broken. There are two ways to extract and examine Type1 fonts: 1. My Perl script xtractfonts extracts Type1 fonts from pdf files (using pdftops at the moment but should work with acroread also) and disassembles them using t1diasm. Adding Eddie's t1lint can be done easily. 2. pdftosrc can be used to extract objects from a pdf file and Hartmut successfully retrieved some fonts and disassembled them using the t1utils. I suppose that pdftosrc can be used to extract other things too and external programs can be used for validation. Thanh, I find http://www.sendspace.com extremely annoying. Unless you forgot your passwd you can copy files to thanh@ms25.ath.cx/public_html and ask people to download them from http://ms25.ath.cx/~thanh . Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------