Conversion Tools ⇒ Pdflatex "No room for a new \string" In directories with lots of files

[user40293]

I'm seeing strange behavior when using pdflatex on a directory with lots of files (80+). I have a simple tex file that imports two other tex files using /import. I was having erratic behavior where sometimes it would generate the pdf, and sometimes it would not. The errors were also not consistent. Sometimes it was No room for a new \string, or \write. Later it was "capacity exceeded". The error in stdout looks something like this:

Code: Select all

(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvdefinekeys.sty))
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/pdftexcmds.sty)
(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg))
*geometry* detected driver: dvips
(./3b.toc) [1
Non-PDF special ignored!
<special> papersize=433.62pt,650.43pt
{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}]

LaTeX Warning: No \author given.

(./1b.tex (./3b.toc) (./9.tex (./3b.toc) (./10.tex [2] (./3b.toc) (./10.tex
(./3b.toc) (./10.tex (./3b.toc) (./10.tex (./3b.toc) (./10.tex (./3b.toc)
(./10.tex [3] (./3b.toc) (./10.tex (./3b.toc) (./10.tex (./3b.toc) (./10.tex
(./3b.toc) (./10.tex (./3b.toc) (./10.tex [4] (./3b.toc)
! No room for a new \write.
\e@ch@ck ...message {No room for a new \string #4}
                                                  \fi \fi 
l.42 \tableofcontents

The files were ones that had built in the past, and then when I tried to build them again, they would fail. What's strange is that there is no 9.tex or 10.tex file anywhere in the source (or the imported) tex files. Although there are ones in the same directory. I don't understand why it's looking for them. I found that if I stripped everything out of the imported tex files, so it was a skeleton almost, it still failed to build. Finally, I moved the tex file from its original directory, put it in a fresh directory, and it built immediately.

Would a directory with say 100 files be a problem to pdflatex? Is there a way to get more detailed output in the log for what it's trying to do? Any help much appreciated. I can provide the imported tex files if requested. Here's the main tex file:

Code: Select all

\documentclass[11pt]{book}
\usepackage{standalone}
\usepackage{import}
\usepackage{graphicx}
\usepackage{caption}
\usepackage{xcolor}
\title{Title of doc}
%for c code (maybe not required)
\usepackage{listings}
\lstset{
basicstyle=\small\ttfamily,
columns=flexible,
breaklines=true
language=C %todo: custom language
}



\paperheight=9in
\paperwidth=6in
\pdfpagewidth=6in
\pdfpageheight=9in

\setlength{\pdfpagewidth}{\paperwidth}
\setlength{\pdfpageheight}{\paperheight}

\usepackage[vcentering,dvips]{geometry}
\geometry{papersize={6in,9in},total={4.5in,6.8in}}

\begin{document}


\tableofcontents

\maketitle

\begin{center}
\textbf{Preface:}
\vspace{0.2in}
\end{center}

placeholder text...


\section{Door}
\import{/home/layoutdev/Desktop/code/documentation_general/Projects_2020/Door/docs/}{1b}

\section{Car Stereo Replacement}
\import{/home/layoutdev/Desktop/code/documentation_general/Projects_2019/Car_Stereo/docs/}{1b}

\end{document}

[Ijon Tichy]

The error message is: "! No room for a new \write." not "No room for a new \string"!

It seems there are to many simultaneously opened *.toc files. and it seems that 10.tex reads recursively 10.tex. Without a really complete minimal working example I cannot say more than already explained.

[user40293]

No room for a new string is taken from the above log, so it is there, but I think you are correct that the write is the proper error.

Regardless, even after moving to a new directory, I ran into another similar cryptic error. This time it is apparently a well-known capacity Tex exceeded error, text input levels=15... So I'm again caught.

I tried the three options given in the link(lua,morewrites,scrwfile). I also tried adjusting max_open_file in a cnf file in /etc/texmf/texmk.d which was reported in a few places. None of them have any effect.

Perhaps I'm going about this the wrong way. I have a number of tex files that are meant to be imported into my collection as articles. So I've decided to use the \import option. I have used \includepdf in the past, where I imported the some 30 or 40 PDF articles, and that worked without any issue. But this time I wanted to get a proper page count, along with an index, and other normal book fodder, but the import option apparently doesn't work after about importing 5 articles.

EDIT: fixed, see below.

[user40293]

I was able to track it down. It appears one of my imported articles had a bibliography in it, and when it imported, it was causing a recursive loop, I guess. By commenting out the bibliography tags, I was able to get what I have of the docs to import. That at least explains one of the errors.

So for others, with a similar problem: Strip everything out, and rebuild piece by piece until things break. Then look for any syntax or latex formatting that shouldn't be in an import file. Very hard to wrap your head around this, when you have dozens of articles to import. More verbosity in logs might be of use.

What was difficult, was how inconsistent this error was. Sometimes it would error out, sometimes it wouldn't, depending on seemingly unrelated circumstances. Just commenting out the bad article didn't always fix things.. I troubleshoot a lot of software, and this was not straightforward. I think there were two different errors at play.

Also don't assume that lualatex, or the other fixes above are the answer. That's a potential rabbit hole.

[Ijon Tichy]

No room for a new string is taken from the above log, so it is there,

But it is not the error message, it is only the source code line (from the LaTeX kernel) of the error message. This is not the same. Perhaps, it would be a good idea to believe the helpers at least in such basics …

And yes, minimizing a document is the recommended way to locate a problem. That's the reason we almost always ask for a minimal working example.

q.e.d.

[user40293]

Just a quick update to this post. I resolved one other issue with package import and exporting to pdf.

All of my draft files follow a convention whereby they are named incrementally (i.e. first draft is 1.tex, second draft is 2.tex and so on). I have a number of import files all with these ##.tex names. And, the main latex file also follows this convention. However, I was getting no room for a new string and no room for a new write errors when I went from 26 to 27 to 28.tex in the main file.

I renamed the main latex file to be <someword>28.tex and it built. From what I can tell, if you have multiple import names of a number, and then also have the main file be of a number, it can break. The best clue I have is:

Code: Select all

Most Recent Backtrace:
========================================================

Transcript written on 28.log.
!  ==> Fatal error occurred, no output PDF file produced!

l.12 \tableofcontents
                                                  \fi \fi
\e@ch@ck ...message {No room for a new \string #4}
! Emergency stop.
?

l.12 \tableofcontents
                                                  \fi \fi
\e@ch@ck ...message {No room for a new \string #4}
! No room for a new \write.
rk/docs/18.tex [125] [126] (./28.toc)
(/home/dev/Desktop/code/documentation_general/me/3dprinting_gettingittowo

Chapter 7.
(./28.tex [122] (./28.toc) [123] [124]
Underfull \vbox (badness 10000) has occurred while \output is active [121])

[][]
Overfull \hbox (12.97931pt too wide) in paragraph at lines 120--121

So by giving the main file a different name than the imports, there are no conflicts. Tricky, but fixed.

If anyone has any advice how to debug this (general GDB guide and what to look for), or is interested in seeing the full working example, let me know and I can provide access. Although getting a small working example for this, I am unable to do with the amount of time I have. And thanks for the help so far. Consider this solved.