Error in .tex file makes latex loop forever
John Forkosh
\documentclass[10pt]{article}
\usepackage{amsmath}
\begin{document}
\[ \array{chars\\0-15:&\Diamond&\Heart} \]
\end{document}
causes latex to emit the error
! Use of \@array doesn't match its definition.
If you reply "q" then it says
OK, entering \batchmode
and then runs forever. Without \usepackage{amsmath}
it emits the same error but quickly runs to completion
after you reply "q".
Now, the \array{...} construction is obviously a latex error,
and I don't really care about the .dvi output produced.
But the "runs forever" part is a real problem. How can
I get latex to not get hung up like this regardless of
silly document errors? Thanks,
--
John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )
John Forkosh
When it rains it pours... the same behavior is also produced
by the following short document
\documentclass[10pt]{article}
\usepackage{amsmath}
\begin{document}
\renewcommand{\input}[1]{\mbox{[[$\backslash$input\{#1\} illegal]]}}
\[ \left(\begin{array} \]
\end{document}
which causes latex to emit the error
! LaTeX Error: Illegal character in array arg.
and also runs forever in \batchmode after you reply "q".
Taking out either the \usepackage or the \renewcommand
allows it to quickly run to completion after replying "q".
Scott Pakin
Are you trying to quit by entering "q"? If so, then you instead need
to enter "x" for "eXit":
$ tex
This is TeX, Version 3.1415926 (Web2C 7.5.7)
**\badcommand
! Undefined control sequence.
<*> \badcommand
? ?
Type <return> to proceed, S to scroll future error messages,
R to run without stopping, Q to run quietly,
I to insert something,
1 or ... or 9 to ignore the next 1 to 9 tokens of input,
H for help, X to quit.
? x
No pages of output.
"q" means "run Quietly", i.e., in batch mode. This causes TeX to ignore
errors and slog ahead as best it can, even if its error-recovery approach
locks it into an infinite loop.
-- Scott
GL
\begin{array}{ preamble }
chars \\
0-15: & \Diamond & \Heart
\end{array}
Robin Fairbairns
i take it this is something inside your mathtex system? does that
emit "q" when it gets an error message from latex? -- seems odd.
--
Robin Fairbairns, Cambridge
John Forkosh
Yes, sir, Robin, you nailed it. I was slightly reluctant to mention
that since it publicizes a way for anybody to create runaway processes
on the mathtex public web service I'm hosting.
> does that emit "q" when it gets an error message from latex?
Yes. After pulling your expression from the ?query_string,
it constructs a file latex.tex containing, more or less,
actually a little more than...
\documentclass[10pt]{article}
\usepackage{amsmath}
\begin{document}
\[ your expression from ?query_string \]
\end{document}
and another file reply.txt containing just the single byte
q
and then from within the C program issues, more or less,
system("/path/to/latex/latex latex.tex < reply.txt");
> -- seems odd.
The thought is that if a user submits an expression
containing some latex syntax error, any .dvi output latex
can produce may help him debug his problem.
The easy solution here, as suggested by Scott, is to put
an x in reply.txt (or just to omit the "< reply.txt" part).
Actually, that's already an option, but q's the current
default. Is that a bad idea?
In any event, I need to apply some kind of fix to make
the program more robust to "silly user input". I'm actually
a little surprised latex (or is it amsmath?) allows this
to happen at all. I'd think unpredictable output is okay
when input contains errors, but no program should ever
let bad input just hang the machine.
Is this a known latex/amsmath behavior? Anybody planning
to change it, or any way I can easily fix it? Otherwise,
what's my best course of action to fix mathtex? Thanks,
Lars Madsen
batchmode and parse the log file
and how do you define silly input?
query:
a=b \]\input{/etc/passwd}\[ a=b
--
/daleif (remove RTFSIGNATURE from email address)
LaTeX FAQ: http://www.tex.ac.uk/faq
LaTeX book: http://www.imf.au.dk/system/latex/bog/ (in Danish)
Remember to post minimal examples, see URL below
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=minxampl
http://www.minimalbeispiel.de/mini-en.html
John Forkosh
Thanks, Scott. As discussed in preceding reply to Robin,
the "q" default was intended to help users "debug" expressions
containing latex syntax errors by showing them any .dvi output
latex could possibly produce. I guess what I need instead is
a "gentler" option to "slog ahead but eXit if locked into a loop".
If there's no middle ground between "q" and "x", then I suppose
"x" has to become the new default. Is that what you'd recommend?
John Forkosh
> John Forkosh a ?crit :
Thanks, GL, but (see preceding reply to Robin) input like
that \array{...} error is coming from a general user population.
So telling them "don't submit input containing errors" won't work.
The program has to robustly handle any input, with or without errors.
John Forkosh
Thanks, Lars, I hadn't thought of that. A little test
is showing me that the .log file indeed exists and is
readable when the error is reported to the screen.
But the "! LaTeX Error: ..." stuff isn't in the .log file
at that point, and only appears there >>after<< you reply
q or x, which is too late to base the q-or-x decision on.
That problem aside, there are two more issues I don't
immediately see how to resolve. First, the process created by
system("/path/to/latex/latex latex.tex < reply.txt");
is already running. I'd have to put latex to sleep, waiting
on a signal issued after parsing the .log file and deciding
how to proceed, ...or something like that. Is there some
way to do that which doesn't involve modifying latex's source?
Second, although I can parse the .log file (if it contains
the "! LaTeX Error:" message), how can I distinguish between
errors that actually cause infinite loops and "benign" errors?
> and how do you define silly input?
:). Well, the only quantifiable characteristic that concerns me
is whether or not input causes latex to hang.
> query: a=b \]\input{/etc/passwd}\[ a=b
Okay, yeah, that too. But mathtex already disables \input,
though I'd agree any attempt to hack/crack the host by
submitting an expression designed to exploit a vulnerability
is also a concern. But besides pulling the plug, I know of no
100% foolproof solution to that general problem. If you've
got a more complete list of dangerous \commands, that would
be helpful.
Lars Madsen
don;t run it in a mode that hangs
>> query: a=b \]\input{/etc/passwd}\[ a=b
>
> Okay, yeah, that too. But mathtex already disables \input,
> though I'd agree any attempt to hack/crack the host by
> submitting an expression designed to exploit a vulnerability
> is also a concern. But besides pulling the plug, I know of no
> 100% foolproof solution to that general problem. If you've
> got a more complete list of dangerous \commands, that would
> be helpful.
classical code injection
well jonathan fine already mentioned this, it is much harder to harden
LaTeX than TeX.
as I mentioned run in bachmode (emacs and latexmk does this) and then
look in the log.
The safest thing to do might be to run LaTeX in a chrooted environment,
but that is not easy to create
I'd just do
latex -interaction=batchmode file.tex
and then parse the log fil. I usally just put the entire log back into
the browser and let the user check it. Making nice interfaces to users
is quite hard. And some errors just does not make sense to the user.
John Forkosh
Thanks again, Lars, I think that'll have to be the solution
(see additional example/remarks at bottom three paragraphs).
>>> query: a=b \]\input{/etc/passwd}\[ a=b
>>
>> Okay, yeah, that too. But mathtex already disables \input,
>> though I'd agree any attempt to hack/crack the host by
>> submitting an expression designed to exploit a vulnerability
>> is also a concern. But besides pulling the plug, I know of no
>> 100% foolproof solution to that general problem. If you've
>> got a more complete list of dangerous \commands, that would
>> be helpful.
>
> classical code injection
>
> well jonathan fine already mentioned this, it is much harder to harden
> LaTeX than TeX.
>
> as I mentioned run in bachmode (emacs and latexmk does this) and then
> look in the log.
>
> The safest thing to do might be to run LaTeX in a chrooted environment,
> but that is not easy to create
Especially not easy when the program runs as a cgi.
And it's one thing for me to do that on my host running the
public web service, but quite another for users who download
the source and run the program on their own machines.
Most of them just want to see some math on their web pages,
without becoming sysadmins or webmasters. So any feasible solution
has to be completely transparent to users.
> I'd just do
>
> latex -interaction=batchmode file.tex
>
> and then parse the log fil. I usally just put the entire log back into
> the browser and let the user check it. Making nice interfaces to users
> is quite hard. And some errors just does not make sense to the user.
Strangely (seems strange to me), -interaction=batchmode still hangs
for the following example
\documentclass[10pt]{article}
\begin{document}
\renewcommand{\input}[1]{dummy renewcommand}
%%\renewcommand{\sqrt}[1]{dummy renewcommand}
%%\renewcommand{\beta}{dummy renewcommand}
\[ \left(\begin{array}{cccc}1 & 0 & 0 &0\\0 & 1 %%% \end{array}\right)
\]
\end{document}
whereas just latex example.tex < reply.txt with an x in file reply.txt
runs to completion (still has the error, of course, but doesn't hang).
That above example also illustrates the following: if you comment out
the \renewcommand{\input} and uncomment either or both of the other
\renewcommand's, then latex runs to completion (with the error, of
course, but without hanging). So there's some weird side effect
specifically with \renewcommand for \input. And that does seem to
me like something that somebody (who knows the internals) might want
to look at sometime.
Meanwhile, the quickest and easiest fix is to put an x rather than a q
in reply.txt (just changing the program's default option is even easier).
Actually, changing the documentation is a bit more work, and I'll submit
the (trivial) CTAN update when finished. For the time being, anyone
reading this and running mathtex on their server should just recompile
their cgi with the -DNOQUIET option on the compile line. That's all you
need to do (assuming not running in quiet mode always fixes the problem).
Scott Pakin
> Thanks, Scott. As discussed in preceding reply to Robin,
> the "q" default was intended to help users "debug" expressions
> containing latex syntax errors by showing them any .dvi output
> latex could possibly produce. I guess what I need instead is
> a "gentler" option to "slog ahead but eXit if locked into a loop".
> If there's no middle ground between "q" and "x", then I suppose
> "x" has to become the new default. Is that what you'd recommend?
You wrote that the "q" is coming from an input file, right? So how
about having the input file instead be
"<Enter><Enter><Enter><Enter><Enter>x<Enter>"? That will let TeX
swallow and log five errors before exiting. Even better, you can use
"q" but run latex using the timelimit command
(http://devel.ringlet.net/sysutils/timelimit/). If mathTeX takes more
than, say, five seconds to typeset a simple math expression, then you
can probably assume it's stuck in an infinite loop. That'll be good
when a jerk like me enters "\def\foo{\foo}\foo" on your site, which
causes latex to chug away for a while -- without producing a TeX error
or even writing anything to the log file -- before issuing an internal
server error.
-- Scott
John Forkosh
> John Forkosh wrote:
>> Thanks, Scott. As discussed in preceding reply to Robin,
>> the "q" default was intended to help users "debug" expressions
>> containing latex syntax errors by showing them any .dvi output
>> latex could possibly produce. I guess what I need instead is
>> a "gentler" option to "slog ahead but eXit if locked into a loop".
>> If there's no middle ground between "q" and "x", then I suppose
>> "x" has to become the new default. Is that what you'd recommend?
Thanks for two excellent suggestions, Scott...
> You wrote that the "q" is coming from an input file, right? So how
> about having the input file instead be
> "<Enter><Enter><Enter><Enter><Enter>x<Enter>"? That will let TeX
> swallow and log five errors before exiting.
Seems obvious now that you've said it, but never occurred to me
until you did. A few preliminary tests show that some expressions
which lock latex into a loop with "q" still lock it into a loop
after six or so <Enter>'s, but two or three (or even four) seem
safe. I'll clearly just make it a compile-time -D option, and
better determine the maximum safe default later.
The most important benefit is for simple syntax errors like
\alpha\beta\gamow\delta where a few <Enter>'s let the user
see an \alpha\beta\delta image, pointing him to the error more
directly than an iimmediate x which shows the user no image at all.
> Even better, you can use
> "q" but run latex using the timelimit command
> (http://devel.ringlet.net/sysutils/timelimit/). If mathTeX takes more
> than, say, five seconds to typeset a simple math expression, then you
> can probably assume it's stuck in an infinite loop. That'll be good
> when a jerk like me enters "\def\foo{\foo}\foo" on your site, which
> causes latex to chug away for a while -- without producing a TeX error
> or even writing anything to the log file -- before issuing an internal
> server error.
This is also a terrific idea that I'll implement as a -D compile option
for users who want to use timelimit and can install it on their hosts.
My preliminary tests work fine from the command line, but are behaving a
little weirdly from within a running program when issued as
system("/path/to/timelimit -t10 -T5 /path/to/latex input.tex < reply.txt");
with or without the "< reply.txt" part, which may be being eaten by
timelimit. I'll just write a small program to better trace what's
going on, which I'm sure will resolve any problems.
Your "\def\foo{\foo}\foo" kinds of problems won't be an issue,
as I'll also be disabling a bunch of dangerous \directives (list
supplied by Steve Mayer -- thanks). But since \renewcommand seems
to have its own dangers (sometimes causing syntax errors to lock latex
in a loop), I'll now handle all command disabling from the C program,
which should be a third solution to the "latex locked in a loop" problem
that started this thread.
Thanks again, Scott, and also everyone else who replied.
Donald Arseneau
wrote:
> Thanks, Scott. As discussed in preceding reply to Robin,
> the "q" default was intended to help users "debug" expressions
> containing latex syntax errors by showing them any .dvi output
> latex could possibly produce. I guess what I need instead is
> a "gentler" option to "slog ahead but eXit if locked into a loop".
> If there's no middle ground between "q" and "x", then I suppose
> "x" has to become the new default. Is that what you'd recommend?
I would send a hundred carriage returns and then x.
But you need more protection anyway because bad documents
don't need to generate any error before going into an endless
loop!
Donald Arseneau
John Forkosh
> John Forkosh <please.see.sig.for.email.com> wrote:
>> Thanks, Scott. As discussed in preceding reply to Robin,
>> the "q" default was intended to help users "debug" expressions
>> containing latex syntax errors by showing them any .dvi output
>> latex could possibly produce. I guess what I need instead is
>> a "gentler" option to "slog ahead but eXit if locked into a loop".
>> If there's no middle ground between "q" and "x", then I suppose
>> "x" has to become the new default. Is that what you'd recommend?
>
> I would send a hundred carriage returns and then x.
Thanks, Donald. I've already changed the program so you
can compile it with a -DNQUIET=n switch which will then
send n returns followed by an x. But I've changed the
default from sending q to sending 3 returns and then x.
That shows images for simple errors like "\sqrt{123",
but stops before any of the examples I gave previously
gets locked into a loop. They're all locked into loops
by 100 returns.
> But you need more protection anyway because bad documents
> don't need to generate any error before going into an endless
> loop!
Got any examples besides Scott's "\def\foo{\foo}\foo"?
I'll be disabling \def,\newcommand,\etc, so that kind
of issue won't be a problem, but I'm no texpert (not even close)
and can't even imagine what else might go wrong that I might
be able to program around.
Donald Arseneau
wrote:
> Donald Arseneau <a...@triumf.ca> wrote:
> > But you need more protection anyway because bad documents
> > don't need to generate any error before going into an endless
> > loop!
>
> Got any examples besides Scott's "\def\foo{\foo}\foo"?
> I'll be disabling \def,\newcommand,\etc, so that kind
> of issue won't be a problem, but I'm no texpert (not even close)
> and can't even imagine what else might go wrong that I might
> be able to program around.
There are many possible ways,
\loop\iftrue\repeat
is obvious.
\everypar{\par} or \everypar{\hrule} produce pages without limit,
whereas some use of \hrule in a tabular where \par is disabled
will silently loop forever.
Furthermore, some "symbols" *require* \def, and you lose them
by disabling it.
Donald Arseneau
John Forkosh
> John Forkosh <j...@please.see.sig.for.email.com> wrote:
>> Donald Arseneau <a...@triumf.ca> wrote:
>> > But you need more protection anyway because bad documents
>> > don't need to generate any error before going into an endless
>> > loop!
>>
>> Got any examples besides Scott's "\def\foo{\foo}\foo"?
>> I'll be disabling \def,\newcommand,\etc, so that kind
>> of issue won't be a problem, but I'm no texpert (not even close)
>> and can't even imagine what else might go wrong that I might
>> be able to program around.
>
> There are many possible ways, \loop\iftrue\repeat is obvious.
> \everypar{\par} or \everypar{\hrule} produce pages without limit,
Thanks again, Donald. \loop's also on Steve Mayer's "blacklist",
and also \everypar, so they shouldn't pose a problem. He's been
following this thread (hi, Steve), and asked in email that I not
post the complete list. But if you (anybody) are curious and want
a copy, it's okay with Steve to email me (john at forkosh dot com)
or him (mayer at dial dot pipex dot com) for one.
> some use of \hrule in a tabular where \par is disabled
> will silently loop forever. Furthermore, some "symbols"
> *require* \def, and you lose them by disabling it.
I'm getting the feeling there's no foolproof solution,
and Steve's list may be as good as it's going to get
without considerable additional effort. And Scott's timelimit
suggestion will hopefully provide a catchall for any pathological
expressions that slip through the cracks (I'll be adding that as
a mathtex option for users who can install timelimit on their
servers). Thanks so much,