# Unclean .aux file causes “file ended while scanning use of \@newl@bel” error. Why is it not purged?

I am working on TeX Live 2013 with TeXShop (MacTex2013 distribution)

Expected behavior is, that in the case an error occurs during compilation the .aux file is purged. Subsequent compilation must therefore be done twice, to get the references right.

In the below "minimal" example, this does not happen. The .aux file remains half written causing a "file ended while scanning use of \@newl@bel" error.

Even minimal changes lead to the .aux file being correctly purged. Such as:

• Change of text in headlines or captions. Even a change of Ü to \"U.
• Omitting a \label{...} anywhere.
• Omitting a \cite{...} anywhere (providing a .bib resource has no effect).
• Not using biblatex or hyperref.
• Changing the page breaks.

Here is the self-contained file.

\documentclass{article}

\usepackage[utf8]{inputenc}
\usepackage[ngerman]{babel}
\usepackage{csquotes}
%\usepackage[T1]{fontenc}

\usepackage{biblatex}

\usepackage{hyperref}

% ================================================

\begin{document}

\clearpage

\section{Geomaxrie der ganzzahligen linearen Optimierung}

\label{Sec.Einfuhrung}

. [figure]

\begin{figure}
\caption{Caption}
\label{Fig.Beispiel-ILP}
\end{figure}

\section{Gitterbasisreduktion und Voronoi Algorithmus}
\label{Sec.Voronoi}

.

.

.

.

.

.

.

.

.

.

cite\cite{Voronoi}

.

.

.

label\label{Thm.Voronoi}

.

.

label\label{Alg.VoronoiFilter}

.

.

label\label{Alg.VoronoiFilter.Bedingung}

.

.

.

.

.

.

.

.

.

label\label{Alg.CVPP}

.

.

.

.

.

.

.

label\label{Alg.VoronoiRelevant}

.

.

.

.

.

.

.

label\label{Alg.Voronoi}

.

\clearpage
\section{Ellipsoid-Überdeckungen und M-Ellipsoide}
\label{Sec.Ellipsoid-Methode.M-Ellipsoide}

. [figure]

\begin{figure}
.
\caption{Löwner-John-Ellipsoid mit Anwendung in der Ellipsoid Methode}
\label{Fig.MinEllipsoid}
\end{figure}

.

.

label\label{Thm.InertEllipsoid}

label\label{Thm.MEllipsoid}

.

.

. [figure]

\begin{figure}
\caption{Label}
\label{Fig.M-Ellipsoidoo}
\end{figure}

label\label{Alg.ConvexBodyEnumerationInformal}

.

.

\clearpage
\section{Berechnungsmodell}
\label{Sec.Berechnungsmodell}

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

cite\cite{M-Ellipsoid}

.

.

.

.

.

.

.

.

.

.

.

.

.

.

label\label{Def.SEP}

.

.

.

.

\section{M-Ellipsoid Algorithmen}

.

label\label{Theorem}

Cause error here: $A simple error at this point results in the .aux file not being cleaned. Even marginal changes in the document above make the effect disappear \end{document}  To reproduce the bug, do the following: 1. Observe the single$ at the end of the document causing an error
2. Compile (.aux remains in an unclean state)
3. Correct the error
4. Compile again (half written .aux causes error)
5. Delete .aux file to recover

I know what happens and how to recover. My question is:

or better

## Is there a way to prevent it?

In my current document, for every error I make while writing in the last section, I have to manually delete the .aux files to recover. Since I compile fairly often while writing, this is an annoyance and I'd like to prevent it.

From what I understand the output to an .aux file is buffered. In case of an error, compilation stops and the current buffer remains unwritten. At this point .aux file contains the buffer chunks already written, which may break anywhere, leaving incomplete definitions.

Normally I then don't work with the TeX engine on the console, but simply correct my error and restart.

I do not understand, what triggers the deletion of the .aux file, which, as the example shows does not work reliably. Possibly due to the biblatex or hyperref package. If you could shed some light on that?

Also of interest:

• Is there something to control the deletion of the .aux file after an error?
• Are there TeX/LaTeX commands I can use to manually flush the output buffer for the .aux file? I could use this command right before the section I am working on. That way, I probably won't have to deal with a corrupt .aux file that often anymore.
• Is there an Option for the pdflatex program so that the output buffers are flushed after an error. In most cases the error does not affect the .aux file, so there is no reason in not finish writing it. In the cases where it does, I would have to delete it then.

There are several related questions here on StackExchange:

• This is seen from time to time with certain editors. You do not mention which editor and LaTeX dist combo you are using. Just delete the .aux files and compile again. – daleif Sep 5 '13 at 13:19
• Did you run this exact example? There should be no errors..? – jon Sep 5 '13 at 13:21
• Now it does produce an error. @daleif, I clarified the editor and distro in the question. You guys were simply too fast, since I accidentally save the question before finishing it. – Tobias Simon Sep 5 '13 at 13:45
• even if you expect your editor/compiler to delete .aux files if there is an error, it's a good thing to check to make sure it was actually done. automatic deletion of potentially faulty .aux (and other derived files -- .toc, .idx, etc.) is a relatively recent addition to latex processors; it's a good idea to become familiar with what happens "under the covers" rather than taking everything for granted. – barbara beeton Sep 5 '13 at 13:51
• Not every error creates a broken aux-file. I delete the aux-file only once or twice in a week (and my editor has a menu entry to do this). In the rest of the time I'm quite happy that most of the aux-file (and other external files) is still there after an error and so saves compilation time. – Ulrike Fischer Sep 5 '13 at 13:54

With the help of When is the aux file read and written? and Barbara Beetons kind assistance I was able to determine what goes wrong and how to prevent it.

This is the problem:

Normally I then don't work with the TeX engine on the console, but simply correct my error and restart.

This is what I should have done on the console:

• Type ?+Return to get an idea of what can be done.
• Simply hit Return repeatedly until Tex is finished.
• Type X+Return to finish the run immediately.
• Type E+Return to have the cursor jump to the point where the error occurred.

What happens is, that TeX buffers the \write commands to the .aux file in two stages. First stage, it waits until a page is shipped out to get the page numbers right. Second stage, it waits until it sees fit to issue a write() system call, to reduce the number of (potentially slow) system calls. This second buffer seemingly does not care, if the chunks it writes to file are self-contained legal TeX since it will complete the file before the TeX run is finished anyway.

In the environment of TeXShop however it is tempting to let TeX hang unfinished after an error. Thus the second output puffer is not flushed and the .aux file possibly left unfinished and in an illegal state.

My personal conclusion from this: Always let TeX finish.

The assumption that TeX will have a chance to finish it's run after it stopped for an error was very reasonable before windowed environments, where it became easy and normal to leave processes hanging in the background.

Things that could be done on software side to facilitate this user behavior:

• Change Tex's second buffer behavior to issue a write() system call in case of an error or to break only into TeX-legal chunks.
• Adjust the environment (TexShop) to either clean the .aux file after a process abortion or provide default input to always correctly finish the process.

Things that the user can do, other than always letting TeX finish:

• Use \include{...}. That way the .aux files of the sections before are closed an finished by the time the error occurs. Chances are the .aux file of your current section isn't large enough yet and no TeX-illegal parts were written.
• Hack something involving \immediate\closeout\@mainaux followed by an \openout\@mainaux and a copy of the contents so they don't get overwritten. This will effectively flush the output buffer. Does not seem worth the effort though.

I Just experienced this same problem and couldn't find any offending code in my tex file. It turns out that the offending text was actually in a citation I had just added to BibText, which I was importing using the biblatex package. There must have been some sort of strange character in the abstract that was included when I exported the citation from PubMed. I removed the entire abstract (since it wasn't going to be displayed in the references anyway), deleted the temp files, and rebuilt my PDF without error.

I find it much faster to kill compilation and simply delete the last line of the corrupted .aux file where the truncated buffer write results in incomplete/illegal TeX, particularly when working with large documents and/or debugging persistent/recurring .aux corruption. This way you can retain the valid portion of the .aux file and don't have to wait for compilation to finish.

In most editors it only takes a few keystrokes to switch focus to the .aux file, skip to the end, and delete the last line, so this can be done quite quickly.

If you prefer to force compilation to finish so all buffered \write's are flushed and the .aux isn't corrupted, you can instruct the compiler to proceed through errors without pausing for user input with the -interaction=nonstopmode option, that way you don't have to keystroke past each of them.

Since the problem is .aux file is damaged, you should let your editor know that you want it compile from scratch each time. For example, in case of using Texify if you use Winedt editor (which is unfortunately not free), this is how you would do it: go to Options->Execution Modes->Texify and then mark "Clean Build". I had the same problem and this solved it.

The same issue I had when working with my thesis. Be careful with the references which you might use from google scholar or some comprehensive files which are probably have different format than your bib package support. Making correct references might solve your problem as I solved it by correcting references.

I just ran into the same problem out of blue. All a sudden, it can't run.

At the end, I copied the whole text into a new file and save it, and it works again!