1

This question may appear similar to How to trace LaTeX errors efficiently? but it is not. Or at least, the suggested remedies do not help me in any way.

I have a text, that was last compiled before a upgrade in latex distribution. The text is in Overleaf, which did major upgrade sometimes in late 2016. I did not change anything within the document, but now it does not want to compile, with an error that does not make sense, it points to the blank line, and if attempt to dissect the document, it moves to other (equally nonsensical) locations within the document. Compile from scratch does not help.

I omit the exact nature of the problem here, because I already emailed the Overleaf support. I am not in hurry with this paper, but I might be on some other occasion, in which case, I would be going mad right now.

What I want to know is, how to effectively trace errors back to the source package which caused this error. That was the question of the author in the related question, but none of the answers comes close to explaining what author really wanted to know - that is, how do I get back in the compilation/inclusion graph?

This should NOT be impossible task. If there is command that LaTeX complains about, it should be defined somewhere, in some of the 10+ packages that are included in my document. How do I find where without downloading their sources separately and do some kind of very naive text search?

Why does not LaTeX specify the "call stack" for God's sake? It knows, where the offending command is coming from, I don't.

Are any good "debuggers" for LaTeX out there?

Edit: Some additional info. I used trace package to get a detailed log, and lo and behold, I found the offending piece:

\put (#1,#2)#3->\@killglue \raise #2\unitlength \hb@xt@ \z@ {\kern #1\unitlengt

Note that last \unitlengt is misspelled, and since my error was complaining about \kern, I have a bug. But I don't know where it comes from.

xmp125a
  • 111
  • 2
  • TeX doesn't know where the command comes from: your source provides input which is 'flat', just the same as if you'd typed it in. – Joseph Wright Dec 21 '17 at 21:41
  • Also, the type of error you talk about may be caused by something 'remote' from where the definition is (for example, altering a line break elsewhere ...) – Joseph Wright Dec 21 '17 at 21:42
  • latex has no record, even internally, of which file defined any command. – David Carlisle Dec 21 '17 at 21:47
  • @DavidCarlisle It does not matter. Then a debugger should provide such functionality. It could be implemented by regexing the packages used. So I assume there is no such debugger? – xmp125a Dec 21 '17 at 21:51
  • It's a rare error that requires that amount of digging. And since macros can be constructed on the fly, a simple regex of the source code won't necessarily find anything. – Alan Munn Dec 21 '17 at 22:00
  • @AlanMunn Well, so I should consider myself extremely unlucky :) ? I searched through all my project files (as far as Overleaf clumsy file-by-file search allows) and cannot find that misspelling. So I obviously uncovered a bug right before Christmas 2017, introduced in late 2016, on a large cloud latex processing platform, used by many many users... – xmp125a Dec 21 '17 at 22:05
  • 4
    there's a latex option -file-line-error. i've never used it, but it has a good reputation. mentioned in a comment to an answer to this question: LaTeX debugging strategies and brace mismatching. i also made a presentation on debugging latex at tug 2017; the slides are linked from here: http://www.gust.org.pl/bachotex/2017-en/program#section-6 -- this gives some hints on digging into multi-file sources to identify the offending file. – barbara beeton Dec 21 '17 at 22:06
  • sometimes the command generating an error will appear as literal text in a package, sometimes it won't debugging macro languages is hard, it's same in c typically it's easier to step through the compiled code than through layers of c pre-processor macro expansion. In most cases it isn't necessary anyway as you can deduce the package from the macro name, eg \LT@i is derived from longtable package code (even though that string does not appear in the package) – David Carlisle Dec 21 '17 at 22:24
  • 2
    \put is defined in the latex format not in a package, but it is impossible to guess the error from the fragment you have shown, please show the full error message from the log file, from ! to ? – David Carlisle Dec 21 '17 at 22:26
  • 2
    the fragment you show does not indicate an error it is the expected log \put (#1,#2)#3->\@killglue \raise #2\unitlength \hb@xt@ \z@ {\kern #1\unitlengt h #3\hss }\ignorespaces the h that you do not show is on the next line. – David Carlisle Dec 21 '17 at 22:47
  • 1
    My approach to debugging in such cases is: (1) Prepare the most minimal example possible. (2) \begin{document}{\tracingall ...}\end{document}. (3) read the log. – Henri Menke Dec 21 '17 at 23:06
  • The problem was solved by the Overleaf support. It was a known issue with CVPR templates which broke after the upgrade. Actually, this does not solve my problem pointed to in this post - I assume there is no automatic tool to do debugging. – xmp125a Dec 22 '17 at 06:16

0 Answers0