\write inserts an outer frozen sequence \endwrite after its argument
(which appears to contain the closing right brace as well). When
trying to access its meaning (just toying around, no good reason,
obviously), I found that it causes a segmentation fault in pdfTeX but
not in TeX.
Namely, \expandafter\test\string first converts the right brace to a
string, removes it, and attempts to get the \meaning of \endwrite. TeX
simply complains about an unbalanced \endwrite (which can probably not
be recovered from), but pdfTeX segfaults. Note that if we replace
\meaning by \string, pdfTeX's behaviour gets back to that of TeX.
This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)
**\def\test#1{\meaning}\write-1{\expandafter\test\string}\bye
entering extended mode
[1Segmentation fault
This is TeX, Version 3.1415926 (TeX Live 2009/Debian)
**\def\test#1{\meaning}\write-1{\expandafter\test\string}\bye
[1
! Unbalanced write command.
Regards,
Bruno
At least, the error message is correct (and the input is incorrect...)
>
>
> Regards,
> Bruno
In pdfTeX 1.40.11 (TeXLive 2010), there's no segfault anymore, although
the error message differs from TeX. As for LuaTeX, it follows TeX, not
pdfTeX.
So the error seems fixed, somewhat.
Best,
Paul
Thank you Paul. I will update to TeXLive 2010 (or 2011) as soon as I
have a better connection. Last time I tried, it took 24h before I gave
up.
Regards,
Bruno
> Le 25/05/2011 01:08, Bruno Le Floch a écrit :
> > Hello,
> >
> > \write inserts an outer frozen sequence \endwrite after its argument
> > (which appears to contain the closing right brace as well). When
> > trying to access its meaning (just toying around, no good reason,
> > obviously), I found that it causes a segmentation fault in pdfTeX but
> > not in TeX.
> >
> > Namely, \expandafter\test\string first converts the right brace to a
> > string, removes it, and attempts to get the \meaning of \endwrite. TeX
> > simply complains about an unbalanced \endwrite (which can probably not
> > be recovered from), but pdfTeX segfaults. Note that if we replace
> > \meaning by \string, pdfTeX's behaviour gets back to that of TeX.
>
> In pdfTeX 1.40.11 (TeXLive 2010), there's no segfault anymore, although
> the error message differs from TeX.
I get the segfault with
\catcode`\{=1
\catcode`\}=2
\catcode`\#=6
\def\test#1{\meaning}
\write16{\expandafter\test\string}
\csname @@end\endcsname\end
pdfTeX 3.1415926-1.40.11-2.2 (TeXLive 2010), i386-linux
--
Heiko Oberdiek
My log says:
%%% LOG %%%
This is pdfTeX, Version 3.1415926-1.40.11 (Web2C 2010) (format=pdftex
2011.5.25) 25 MAY 2011 11:57
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
**C:/texlive/texmf-local/tex/plain/pitex/test_fonts.tex
(c:/texlive/texmf-local/tex/plain/pitex/test_fonts.tex [1
! Emergency stop.
<inserted text> }\endwrite
\plainoutput ...headline \pagebody \makefootline }
\advancepageno \ifnum
\out...
<output> {\plainoutput
}
<to be read again>
\end
l.1 ...ning}\write-1{\expandafter\test\string}\bye
access violation
! ==> Fatal error occurred, no output PDF file produced!
%%% ENDLOG %%%
"access violation" didn't print on the command line, which is why I've
missed it in my previous message. Is that a segfault (yeah, I'm totally
incompetent here)? At least the message differs from Bruno's. Does it
mean anything?
Since we're at it, XeTeX (not LuaTeX, again) also reports "access
violation".
Best,
Paul
> I get the segfault with
> \catcode`\{=1
> \catcode`\}=2
> \catcode`\#=6
> \def\test#1{\meaning}
> \write16{\expandafter\test\string}
>
> \csname @@end\endcsname\end
>
> pdfTeX 3.1415926-1.40.11-2.2 (TeXLive 2010), i386-linux
On miktex the document crashes too (a windows "problem report" pops
up).
Affected are
pdfTeX, Version 3.1415926-1.40.11 (MiKTeX 2.9) and
XeTeX, Version 3.1415926-2.2-0.9997.4 (MiKTeX 2.9)
tex works fine, and luatex seems to work fine too (but as it is
quite old in miktex this doesn't say much).
--
Ulrike Fischer
This is test.tex:
\catcode`\{=1
\catcode`\}=2
\catcode`\#=6
\def\test#1{\meaning}
\write16{\expandafter\test\string}
\csname @@end\endcsname\end
On MiKTeX 2.4 the behavior concerning the creation of output-files (dvi/pdf)
differs from engine to engine.
Using MiKTeX 2.4, TeX (TeX of MiKTeX 2.4 comes without eTeX support) I get:
===========================================================================
This is TeX, Version 3.141592 (MiKTeX 2.4) (preloaded format=plain 2004.8.31) 25 MAY 2011 13:14
**test.tex
(test.tex [1
! Unbalanced write command.
<recently read> \end
l.7 \csname @@end\endcsname\end
? x
Output written on test.dvi (1 page, 140 bytes).
Using MiKTeX 2.4, pdfTeX (pdfTeX of MiKTeX 2.4 comes without eTeX support) I get:
=================================================================================
This is pdfTeX, Version 3.141592-1.21a (MiKTeX 2.4) (preloaded format=plain 2004.8.31) 25 MAY 2011 13:14
**test.tex
(test.tex [1
! Unbalanced write command.
<recently read> \end
l.7 \csname @@end\endcsname\end
? x
No pages of output.
Funny is:
With TeX you are told that output is written to test.dvi.
After the TeX-run that file exists, it has 140 Bytes and when viewing it,
the dvi-viewer shows an empty page.
With pdfTeX you are told that no output is written at all.
Nonetheless after the TeX-run you have a file test.pdf with 0 bytes.
The pdf-viewer "tells" that it is corrupted.
Using MiKTeX 2.4, LaTeX (LaTeX of MiKTeX 2.4 comes wit eTeX support) I get:
===========================================================================
This is e-TeX, Version 3.141592-2.2 (MiKTeX 2.4) (preloaded format=latex 2004.8.31) 25 MAY 2011 13:22
entering extended mode
**test.tex
(test.tex
LaTeX2e <2003/12/01>
Babel <v3.8g> and hyphenation patterns for english, dumylang, nohyphenation, ge
rman, ngerman, french, loaded.
)
Here is how much of TeX's memory you used:
7 strings out of 95890
40 string characters out of 1195146
44793 words of memory out of 1048577
3151 multiletter control sequences out of 60000
3640 words of font info for 14 fonts, out of 1000000 for 2000
14 hyphenation exceptions out of 4999
5i,1n,1p,46b,11s stack positions out of 5000i,500n,10000p,200000b,32768s
No pages of output.
Using MiKTeX 2.4, pdfLaTeX (pdfLaTeX of MiKTeX 2.4 comes wit eTeX support) I get:
=================================================================================
This is pdfeTeX, Version 3.141592-1.21a-2.2 (MiKTeX 2.4) (preloaded format=latex 2004.8.31) 25 MAY 2011 13:22
entering extended mode
**test.tex
(test.tex
LaTeX2e <2003/12/01>
Babel <v3.8g> and hyphenation patterns for english, dumylang, nohyphenation, ge
rman, ngerman, french, loaded.
)
Here is how much of TeX's memory you used:
8 strings out of 95504
96 string characters out of 1189306
44794 words of memory out of 1048577
3215 multiletter control sequences out of 60000
3640 words of font info for 14 fonts, out of 1000000 for 2000
14 hyphenation exceptions out of 8191
5i,1n,1p,46b,11s stack positions out of 5000i,500n,10000p,200000b,32768s
PDF statistics:
0 PDF objects out of 300000
0 named destinations out of 300000
1 words of extra memory for PDF output out of 65536
No pages of output.
Both with LaTeX and pdfLaTeX I do not get any output-files.
Ulrich
This is test.tex:
\catcode`\{=1
\catcode`\}=2
\catcode`\#=6
\def\test#1{\meaning}
\write16{\expandafter\test\string}
\csname @@end\endcsname\end
On MiKTeX 2.4 both the behavior concerning the creation of output-files
(dvi/pdf) and error-message differs from engine to engine. (There is no
error-message at all with engines with e-TeX-support.)
Using MiKTeX 2.4, TeX (TeX of MiKTeX 2.4 comes without eTeX support) I get:
===========================================================================
This is TeX, Version 3.141592 (MiKTeX 2.4) (preloaded format=plain 2004.8.31) 25 MAY 2011 13:14
**test.tex
(test.tex [1
! Unbalanced write command.
<recently read> \end
l.7 \csname @@end\endcsname\end
? x
Output written on test.dvi (1 page, 140 bytes).
Using MiKTeX 2.4, pdfTeX (pdfTeX of MiKTeX 2.4 comes without eTeX support) I get:
=================================================================================
This is pdfTeX, Version 3.141592-1.21a (MiKTeX 2.4) (preloaded format=plain 2004.8.31) 25 MAY 2011 13:14
**test.tex
(test.tex [1
! Unbalanced write command.
<recently read> \end
l.7 \csname @@end\endcsname\end
? x
No pages of output.
Funny is:
With TeX you are told that output is written to test.dvi.
After the TeX-run that file exists, it has 140 Bytes and when viewing it,
the dvi-viewer shows an empty page.
With pdfTeX you are told that no output is written at all.
Nonetheless after the TeX-run you have a file test.pdf with 0 bytes.
The pdf-viewer "tells" that it is corrupted.
With both engines I get an error about unbalanced write command.
No pages of output.
No pages of output.
Both with LaTeX and pdfLaTeX I do neither get any output-file
nor an error-message.
Ulrich
> Funny is:
> With TeX you are told that output is written to test.dvi.
> After the TeX-run that file exists, it has 140 Bytes and when viewing it,
> the dvi-viewer shows an empty page.
But there is nothing in the test file that would be
visible anyway. Oh, maybe the page number.
How did you get to that stage? the test file is expected to
trap you in the write mode, from which you can only escape
by interrupt and/or typing "x". Of course the segfault, on
those engines, causes the OS to abort the job immediately.
Using TeX, but \immediate\write gives slightly different errors
Runaway text?
\outer macro: \par There \par \@@end \end \par
! File ended while scanning text of \write.
<inserted text>
}
Then you get the Unbalanced write error.
> With pdfTeX you are told that no output is written at all.
> Nonetheless after the TeX-run you have a file test.pdf with 0 bytes.
> The pdf-viewer "tells" that it is corrupted.
This is because the job terminates abrubtly part way through
writing a dvi page.
Donald Arseneau as...@triumf.ca
> Ulrich D i e z <eu_an...@web.de> writes:
>
> > Funny is:
> > With TeX you are told that output is written to test.dvi.
> > After the TeX-run that file exists, it has 140 Bytes and when viewing it,
> > the dvi-viewer shows an empty page.
>
> But there is nothing in the test file that would be
> visible anyway. Oh, maybe the page number.
>
> How did you get to that stage? the test file is expected to
> trap you in the write mode, from which you can only escape
> by interrupt and/or typing "x".
See the log-files attached in my previous posting.
Using those MiKTeX 2.4-engines that do not have e-TeX-support
(TeX, pdfTeX), I got an error-message and pressed "x".
Using those MiKTeX 2.4-engines that do have e-TeX-support
(LaTeX, pdfLaTeX), I neither got an error-message nor needed
to press "x".
(I run via the command-prompt of my nostalgic Win'95 machine. )
Ulrich