latest beta goes into an eternal error loop
Hi, I've found a problem in the latest beta. Previous versions of pdftex would crash (segfault) on this input: {\pdfoutput=1 \immediate \pdfobj stream {}}Hello\bye The latest beta gives a nice "you can't change \pdfoutput" error, but it keeps on repeating that error message until the harddisk is full :-( Taco
2006/8/14, Taco Hoekwater
I've found a problem in the latest beta. Previous versions of pdftex would crash (segfault) on this input:
{\pdfoutput=1 \immediate \pdfobj stream {}}Hello\bye
The latest beta gives a nice "you can't change \pdfoutput" error, but it keeps on repeating that error message until the harddisk is full :-(
I can't reproduce this: -------------------------- This is pdfTeX, Version 3.141592-1.40.0-beta-20060811 (Web2C 7.5.5) entering extended mode (./loop.tex [1{/home/ms/.texmf-var/fonts/map/pdftex/updmap/pdftex.map}] ) Output written on loop.pdf (1 page, 3992 bytes). Transcript written on loop.log. -------------------------- Best Martin
Martin Schröder wrote:
2006/8/14, Taco Hoekwater
: I've found a problem in the latest beta. Previous versions of pdftex would crash (segfault) on this input:
{\pdfoutput=1 \immediate \pdfobj stream {}}Hello\bye
The latest beta gives a nice "you can't change \pdfoutput" error, but it keeps on repeating that error message until the harddisk is full :-(
I can't reproduce this:
What if you start with an explicit \pdfoutput=0 ?
Here's a backtrace of the crash in 0725: Program received signal SIGSEGV, Segmentation fault. 0x00002ba69bf3ada4 in fwrite () from /lib64/libc.so.6 (gdb) bt #0 0x00002ba69bf3ada4 in fwrite () from /lib64/libc.so.6 #1 0x0000000000452075 in closefilesandterminate () at pdftex3.c:6395 #2 0x0000000000410d59 in mainbody () at pdftexini.c:5649 #3 0x000000000045dc1e in main (ac=<value optimized out>, av=<value optimized out>) at pdftexextra.c:340 (gdb) list 6390 decr ( k ) ; 6391 } 6392 if ( dvilimit == halfbuf ) 6393 writedvi ( halfbuf , dvibufsize - 1 ) ; 6394 if ( dviptr > 0 ) 6395 writedvi ( 0 , dviptr - 1 ) ; 6396 printnl ( 971 ) ; 6397 printfilename ( 0 , outputfilename , 0 ) ; 6398 print ( 285 ) ; 6399 printint ( totalpages ) ; Obviously the change of \pdfoutput confuses pdfTeX. Best Martin
On Mon, 14 Aug 2006, Martin Schröder wrote:
Obviously the change of \pdfoutput confuses pdfTeX.
it's a silly loop through fix_pdfoutput, pdf_error, succumb, close_files_and_terminate to fix_pdfoutput again. No clear idea yet what the right way is to break the loop. Regards, Hartmut
Hartmut Henkel wrote:
On Mon, 14 Aug 2006, Martin Schröder wrote:
Obviously the change of \pdfoutput confuses pdfTeX.
it's a silly loop through fix_pdfoutput, pdf_error, succumb, close_files_and_terminate to fix_pdfoutput again.
No clear idea yet what the right way is to break the loop.
Perhaps a succumb() is called for. If someone fiddles with \pdfoutput after something has already been written, chances are that the output will be junk anyway. Taco
On Mon, 14 Aug 2006, taco hoekwater wrote:
Perhaps a succumb() is called for. If someone fiddles with \pdfoutput after something has already been written, chances are that the output will be junk anyway.
currently the easiest seems to make a new boolean variable remembering that there was this error message by fix_pdfoutput, so that the message is given only once. Then it stops nicely with "Fatal error occurred..." Is this too ugly? Regards, Hartmut
Hartmut Henkel wrote:
On Mon, 14 Aug 2006, taco hoekwater wrote:
Perhaps a succumb() is called for. If someone fiddles with \pdfoutput after something has already been written, chances are that the output will be junk anyway.
currently the easiest seems to make a new boolean variable remembering that there was this error message by fix_pdfoutput, so that the message is given only once. Then it stops nicely with "Fatal error occurred..." Is this too ugly?
sounds ok to me, also, delete the dvi / pdf fiel then Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
2006/8/14, Hartmut Henkel
currently the easiest seems to make a new boolean variable remembering that there was this error message by fix_pdfoutput, so that the message is given only once. Then it stops nicely with "Fatal error occurred..." Is this too ugly?
We already have the variable. The enclosed patch does what we want. Best Martin
Martin Schröder wrote:
2006/8/14, Hartmut Henkel
: currently the easiest seems to make a new boolean variable remembering that there was this error message by fix_pdfoutput, so that the message is given only once. Then it stops nicely with "Fatal error occurred..." Is this too ugly?
We already have the variable. The enclosed patch does what we want.
Thanks, great. Taco
On Mon, 14 Aug 2006, Taco Hoekwater wrote:
I've found a problem in the latest beta. Previous versions of pdftex would crash (segfault) on this input:
{\pdfoutput=1 \immediate \pdfobj stream {}}Hello\bye
The latest beta gives a nice "you can't change \pdfoutput" error, but it keeps on repeating that error message until the harddisk is full :-(
Not here. Weird. This is pdfTeXk, Version 3.141592-1.40.0-beta-20060811 (Web2C 7.5.5) (format=pdftex 2006.8.14) 14 AUG 2006 19:21 %&-line parsing enabled. **xx (./xx.tex [1{/usr/local/texlive/2005/texmf-var/fonts/map/pdftex/updmap/pdftex.m ap}] )<./cmr10.pfb> Output written on xx.pdf (1 page, 3991 bytes). PDF statistics: 11 PDF objects out of 1000 (max. 8388607) 0 named destinations out of 1000 (max. 131072) 5 words of extra memory for PDF output out of 10000 (max. 10000000) Regards, Hartmut
participants (5)
-
Hans Hagen
-
Hartmut Henkel
-
Martin Schröder
-
taco hoekwater
-
Taco Hoekwater