After a TeX Live upgrade, main memory capacity errors persist despite raising main_memory in texmf.cnf

Question

Capacity error after configuration change

I am working with a Web2C-based TeX setup (pdfTeX, TeX Live-style configuration) where a large document reliably fails with a main memory capacity error. The failure reproduces at the same point in the log for identical input, engine, and format, which suggests a fixed-table limit rather than a leak. I raised main_memory (and considered extra_mem_top/extra_mem_bot) in texmf.cnf, but the error still occurs at the same place.

My uncertainty is where the effective limit is actually set. I understand that some capacities are baked into the format file (.fmt) at generation time, so a configuration change may require regenerating the format to take effect, and that parameter names and defaults vary between TeX Live, MiKTeX, and engine builds. I also want to avoid masking a pathological package loop by only enlarging tables.

Questions

Which memory-related texmf.cnf variables require format regeneration before they apply to pdfTeX, and which are read at runtime?
How can I confirm from the log's memory statistics whether the failure is a genuine capacity limit versus unbounded growth from document or package code?
Is testing under a second engine (e.g., LuaTeX with dynamic allocation) a valid way to separate a document pathology from a configuration limit?

Tasadduq Burney · Answer

When a pdfTeX document fails with a main memory capacity error after a TeX Live upgrade, and raising main_memory in texmf.cnf has no effect, the most likely cause is that the format file (.fmt) compiled the previous limit values at generation time. pdfTeX reads those baked-in values at startup; runtime changes to texmf.cnf are ignored until the format is regenerated.Variables that require format regenerationmain_memoryextra_mem_topextra_mem_bothash_extrahash_primeparameter_stackfont_mem_sizeThese are compiled into the .fmt header during initex or format dump. Changing texmf.cnf alone does not override them.Confirming the limit from the logExamine the final lines of the pdfTeX log. Look for a line such as:main memory usage: N of M (%)hash table entries: N of MIf main memory usage is near 100% at the point of failure, the error is a genuine capacity limit and regenerating the format is the correct step. If usage is well below 100%, the bottleneck is likely another fixed table (hash size, font memory, etc.) or unbounded growth from packages; the log's hash table entry percentage provides a secondary clue.Testing under a second engineRunning the same source under LuaTeX can help separate a pdfTeX-specific table limit from document-level pathology. LuaTeX uses a dynamic allocation model for many tables, so a document that exhausts pdfTeX's fixed tables may run to completion under LuaTeX. However, LuaTeX has its own limits (node memory, token stack depth) and does not guarantee identical behavior; a successful run under LuaTeX suggests the source is not pathological, but a continued failure indicates a document issue that persists across engines.To confirm, check the log's final main memory usage percentage. If near 100%, regenerating the format with the updated texmf.cnf values is the recommended next step. If it remains well below 100%, other fixed tables may be the bottleneck.

After a TeX Live upgrade, main memory capacity errors persist despite raising main_memory in texmf.cnf

Capacity error after configuration change

Questions

1 answer

Variables that require format regeneration

Confirming the limit from the log

Testing under a second engine

Your perspective belongs here.

0 question comments