I have a couple of LaTeX files with the same problem. If I produce an error, fix it, and then try to compile a pdf, I get the following error.

)Runaway argument?
! File ended while scanning use of \@newl@ablel.
<inserted text>
l.90 \begin{document}

If I then click on the console or trash my .aux file, it compiles fine. Any thoughts on what is going on and how to prevent this annoying extra step?

  • I hope you mean compile a TeX file. :) Aug 7, 2013 at 19:52
  • 1
    Welcome to TeX.SX! Unfortunately, some bad errors cause corruption in the .aux file. Sometimes just passing over the error, instead of interrupting the LaTeX run, can cure it by writing a correct file at the end of the run.
    – egreg
    Aug 7, 2013 at 19:53
  • But once the error is fixed and the corrupt .aux file is deleted, that file compiles fine? Obviously, not every error should produce so terrible an error. Also: is 'the same problem' due to the same bad command..?
    – jon
    Aug 7, 2013 at 22:14
  • This is the weird thing. Once a file decides it wants to do this, it doesn't matter what type of error, the same problem happens. However, lots of my files recompile just fine after clicking apply. From the responses I have gotten, it sounds like I just need to deal with it.
    – user34798
    Aug 8, 2013 at 0:21
  • never saw \@newl@ablel but only \@newl@bel ...
    – user4686
    Jan 23, 2016 at 21:49

2 Answers 2


This is the nature of the beast...

TeX employs an (external) auxiliary .aux file to store information at/of every run. This file is used extensively when dealing with labels and references (see Understanding how references and labels work) since the output routine only flushes pages after having collected enough content to fill it (and perhaps more). As is evident from your error snippet, it deals with an offending \label usage.

Here's the sequence that causes the error:

  1. You compile your document.
  2. \label-information is stored in .aux. This information will be read during a subsequent compilation. If problematic code is written to the .aux, you will only pick it up in this subsequent run. However, this run itself may compile without problem.
  3. You compile your document again in order to make sure the references settle. However, now the problematic code is read in, causing the error.

Note that, even during the second compile (item 3 above) you are still writing problematic code to the .aux. So, even if you fix it and recompile, the problem will still show in the subsequent compile.

Some problems are recoverable, but others are fatal, depending on when you are writing the information to the .aux. In a worst-case scenario - when the problem persists even though you've fixed your code - delete the offending .aux and recompile (at least twice).

How do you avoid this annoying extra step? Don't make mistakes... :) Well, at least not when dealing with content written to the .aux file.

  • Please note my counter-answer. Jan 23, 2016 at 13:30

Although there is already an answer to this question, I think it is wrong. TeXShop users are always complaining about this problem and hardly any other people are complaining. I've been a TeXShop fan almost since the first edition but this is its most annoying feature. It happens to me all the time in TeXShop and almost never in any other program I use, including manual command line execution.

The reason it happens is something to do with the state TeXShop leaves the aux file in when typesetting is aborted at an error. That is, if compilation stops at an error, then you fix the error and hit compile again, latex sees a bad aux file. To see that it isn't (usually) your latex error that caused the bad aux file, instead of starting the compilation again immediately, enter "x" into the window at the bottom of the console window to make latex continue to the end regardless of errors. Now fixing the error and compiling again will usually work.

As several people noted above, deleting the aux file automatically is a bad idea. What should happen (though I don't know how to automate it) is that the aux file is deleted if it wasn't written completely.

  • 2
    This is a great answer and clarifies a lot for me, but something still confuses me. This doesn't happen every time, but once it starts happening it rarely stops, even if the aux file is completely deleted. This suggests to me that there is something about the actual TeX file that causes TeXShop to leave the aux file in a bad state. Do you have an idea what this could be?
    – Will Sawin
    Aug 25, 2017 at 7:00
  • Well guess what. VS code's latex workshop also has this issue. And what's worse, it automatically trashes the aux file to solve this. What's worser, it also trashes the bbl file. What a genius.
    – Symbol 1
    Aug 30, 2021 at 1:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.