# How to trace Latex error back to package that caused it?

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.

• 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
• 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: 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
• \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
• 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
• 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