# Find error in multifile document

I am receiving the following error when I try to compile my multifile document:

! Extra }, or forgotten \endgroup. l.335

Which of course happens from time to time. However, the log does not show in which file the error is occurring. Most of the time it does, or I can find the error based on context, but here it seems the error could be anywhere on line 335. I have gone through all files of the document and looked at line 335 and surrounding areas, but I cannot locate this error.

I already looked at this Q/A and found the last file loaded was name-master.bbl which did not seem to have any errors at line 335. Otherwise, in that Q/A, the issue seemed more related to the old version tex composer the OP was using.

Before this happened, I was converting biblatex cite commands from [natbib=true] (e.g. \citep) to conventional biblatex citation commands (e.g. \parencite{foo}). Jabref will throw an error if I have unpaired braces (which I use to keep title capitalization, etc.) in my .bib file, and I have gone through all of the newly updated citations, and I'm still getting this error.

Anyone have other suggestions for how to track this down- I can't compile my thesis!!

• Eliminate one file at a time by commenting out inclusions. Am I making sense? – ajeh Aug 11 '14 at 20:04
• Try running pdflatex (or other engine) with the -file-line-error option. – egreg Aug 11 '14 at 20:13
• @ajeh Tried that. Strangely even after removing all \input files that I modified since the problem started, the error still occurs! – charles Aug 11 '14 at 20:41
• @egreg Will try that and report on the result. – charles Aug 11 '14 at 20:42
• @egreg The problem seems to be with the master.bbl file. If I delete this file, will pdflatex recreate it? It seems like it keeps using an old version of the file (i.e. timestamp is older than newest pdflatex output files.) – charles Aug 11 '14 at 20:51

[Hmmm...having typed in this answer I notice that the question is already solved in the comments...if there's no interest perhaps I'll delete especially as I don't mention bbl files, although they appear in the log as described below.]

Every time that (La)TeX opens a file it writes (filename... to the log file and it prints a matching ...) when it closes this file. This applies to any files that you \input or \include and to any package or style files that you use. On top of this, whenever page x is created then [x] is printed to the log file. Because of this you can always tell from the log file in which file the problematic line number appears.

For example, suppose that I have the file (the included files a.tex, b.tex, c.tex are all empty):

\documentclass{article}
\usepackage{blindtext}
\begin{document}

\blindtext
\input a   % an example input file
\blindtext
\include b % an example include file
\blindtext
\input c
\blindtext

\end{document}


Then my log file contains:

(/path to/t.tex
...
(/usr/local/texlive/2014/texmf-dist/tex/latex/base/article.cls
(/usr/local/texlive/2014/texmf-dist/tex/latex/base/size10.clo
...
)
...
) (/usr/local/texlive/2014/texmf-dist/tex/latex/blindtext/blindtext.sty
(/usr/local/texlive/2014/texmf-dist/tex/latex/tools/xspace.sty
Package: xspace 2009/10/20 v1.13 Space after command names (DPC,MH)
)
) (./t.aux)
...
(./a.tex)
[1 {/usr/local/texlive/2014/texmf-var/fonts/map/pdftex/updmap/pdftex.map}]
...
(./b.tex) (./c.tex) [2]
(./t.aux (./b.aux)) )


I have gone a little overboard in that I have given excerpts from the log for all of the included files, just to make a point the LaTeX tells you whenever it loads and file. More importantly, I find, TeX also tells you the page numbers as it produces them -- as I normally know the map from page numbers to input files I find that this is the easiest way to tell where the problem lies when I have many include files.

If you run tex manually from the command line then it is easy to see this information as it is printed out. If you run if automatically through your editor then you can still "manually" look at the log file -- although, quite likely your editor can take you straight to problematic line even when you use multiple files (vim can).

• Thanks, but I still think this question would be helpful for noobs such as myself- well I'm less a noob now thanks to Tex SX. As I mentioned, the only other question similar to this dealt more with the editor rather than Tex/LaTeX itself. Still, I leave it to you and the Mods to determine the fate of this Q/A. – charles Aug 11 '14 at 21:57
• @charles I'm not objecting to your question but to my answer:) IMHO, TeX.SX has too many questioned answered in the comments! – user30471 Aug 11 '14 at 22:12