14

When I added a couple of rather unremarkable tables to my document, it stopped compiling (using pdflatex):

"TeX capacity exceeded (main memory)"

I searched the web a bit (well, actually, mostly tex.SE), and found mention that using lualatex should avoid memory issues. So I tried running the code with lualatex, and got

"Too many unprocessed floats"

So, I tried to come up with a minimal working example, and was surprised to find that this little bit of code was sufficient to trigger the problem:

\documentclass{scrbook}

\usepackage[ngerman]{babel}
\usepackage[T1]{fontenc}

\begin{document}

\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}
\begin{table*}\begin{tabular}{|c|}Foo\\\end{tabular}\end{table*}

\end{document}

Apparently, I am missing something essential here, as 19 "simple" tables shouldn't be bringing LaTeX down...?!?

Improve this question
11
  • 1
    There is an entry in the TeX FAQ about too many unprocessed floats: tex.ac.uk/cgi-bin/texfaq2html?label=tmupfl
    – Torbjørn T.
    Commented Nov 21, 2011 at 10:58
  • 1
    It seems that you don't need babel nor fontenc in the MWE. The MWE should also be complete for a simpler document class such as article.
    – N.N.
    Commented Nov 21, 2011 at 11:10
  • 3
    @DevSolar meta.tex.stackexchange.com/questions/228/… reads '"minimal" in minimal working example means that the document should not contain any (yes any!) code which isn't related to the error. If a code line can be removed without changing the error/issue it doesn't belong into the example. If a non-standard class is used for the original document and the error/issue still happens with a standard class then a standard class should be substituted.' Also, minimalism contributes to generality.
    – N.N.
    Commented Nov 21, 2011 at 11:54
  • 1
    @DevSolar: It is not code-golf. It is to maximise the chance of you getting an answer. Whilst this case is a mild example, we often have situations where people post vast swathes of code, including many, many unnecessary packages. Then figuring out which package (or combination of packages) actually led to the error is a tedious task which is better done by the questioner than the answerer. As I said, this case is mild but it may be that someone else with this problem comes across your post and thinks it not relevant because they're not using babel, fontenc, or scrbook.
    – Andrew Stacey
    Commented Nov 21, 2011 at 12:25
  • 1
    (ctd) if you have specific requirements on the solution ("Must be compatible with scrbook") then those are best said in accompanying text. Having them in the example code is not equivalent since it isn't clear that you have to use scrbook just from looking at your code: you do use it, but you don't say you have to. So keeping your code minimal and your explanation full (but not excessively verbose!) makes it easier to understand both the problem and what form the solution has to take, making it easier to answer the question.
    – Andrew Stacey
    Commented Nov 21, 2011 at 12:27

3 Answers 3

Reset to default
10

You can use the command \clearpage. This prints all floats that are not yet placed and starts a new page.

Improve this answer
3
  • This, indeed, solved the problem. In the actual document I am working on, the table*'s I added are full-page anyway, so \clearpage is a clean solution.
    – DevSolar
    Commented Nov 21, 2011 at 11:06
  • 1
    As egreg points out in his answer the problem is related to the positioning of the tables. My usual approach is to use the afterpage package to do something like \afterpage{\clearpage} to control the placement of big tables and figures. I usually go for filling the right page in a twoside document leaving a page of text on the left and a page floats on the right on a spread.
    – Steffen V.F.
    Commented Nov 21, 2011 at 12:37
  • +1 I was thinking I have had this problem and now how did I solve it again... but this was it.
    – DQdlM
    Commented Nov 21, 2011 at 14:35
18

Each float is pushed in a queue, which is capable to contain only 18 objects (allocated as boxes \bx@A to \bx@R).

This may be extended: the package morefloats was written just for this. However the error "Too many unprocessed floats" is usually caused by too strict limits on float positioning: a table specified with

\begin{table}[!h]

and which can't be placed "there" will block all subsequent floats until coming to a \clearpage command (maybe issued by \chapter) or the end of the document. If 18 floats follow it, the error will be issued.

Improve this answer
2
  • 18
    Of course one immediately begins to wonder: "Why eighteen?!" And it turns out that 18 one-line tables with 10 point Computer Modern using article.cls produces almost exactly one page worth of material.
    – kahen
    Commented Nov 21, 2011 at 11:10
  • @kahen Nice remark, never thought about that.
    – egreg
    Commented Nov 21, 2011 at 11:15
2

From LaTeX 2015/10/01 onwards the default size of the float queue is raised from 18 to 52. Also it may be made larger (several thousand) using the command \extrafloats added in the 2015/01/01 release.

Despite the above, egreg's answer is still valid, if the float options or constraints are preventing good float placement, having a longer float queue means it just takes longer to be told that floats can not be placed.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .