Dear TeX(-k) people, dear pdfTeX team,
late last year Norbert Preining already asked on the TeXk list about a
problem encountered in Debian, namely a TeX capacity exceeded error on
grouping levels. Nobody could help back then, but now someone started to
analyse this further (many thanks, Stijn!). So could you please (again)
have a look?
It seems the value is hardcoded in the sources,
"Stijn van Drongelen"
The issue seems to have its roots in build/source/texk/web2c/tex.web, line 5925-5930:
if cur_level=max_quarterword then overflow("grouping levels", @:TeX capacity exceeded grouping levels}{\quad grouping levels@> max_quarterword-min_quarterword); {quit if |(cur_level+1)| is too big to be stored in |eqtb|} cur_boundary:=save_ptr; incr(cur_level); incr(save_ptr); cur_group:=c; end;
So if 'cur_level' exceeds the maximum quarterword size, TeX dies. These constants are defined in 2411-2414:
@d min_quarterword=0 {smallest allowable value in a |quarterword|} @d max_quarterword=255 {largest allowable value in a |quarterword|} @d min_halfword==0 {smallest allowable value in a |halfword|} @d max_halfword==65535 {largest allowable value in a |halfword|}
And on line 2409, it says: "The values defined here are recommended for most 32-bit computers."
I use amd64. I can deal with max_quarterword=65535 etc.
Why aren't these quarterword/halfword bounds configurable?
There is a configuration variable nest_size level, but it doesn't seem to help in this case: The attached file gives an error ! TeX capacity exceeded, sorry [grouping levels=255]. although my texmf.cnf has nest_size=500. Should/can we change max_quarterword, or are there side effects? Or should the grouping levels instead use halfword? Or would you like to do it in a completely different way? This is a real life problem which affects building the PostgreSQL documentatin. Many thanks in advance, Frank -- Frank Küster Debian Developer (teTeX/TeXLive)
Hi Frank, Stijn, Frank Küster wrote:
Dear TeX(-k) people, dear pdfTeX team,
late last year Norbert Preining already asked on the TeXk list about a problem encountered in Debian, namely a TeX capacity exceeded error on grouping levels. Nobody could help back then, but now someone started to analyse this further (many thanks, Stijn!). So could you please (again) have a look?
Why aren't these quarterword/halfword bounds configurable?
They simply cannot be configurable at runtime because that would be too late, the entire memory structure depends on these sizes.
There is a configuration variable nest_size level, but it doesn't seem to help in this case: The attached file gives an error
! TeX capacity exceeded, sorry [grouping levels=255].
although my texmf.cnf has nest_size=500.
Should/can we change max_quarterword, or are there side effects?
Technically, at compile time we could have max_quarterword=65535 and even max_halfword=2^30 on all modern platforms, but it more or less requires switching to the memory_word structure used by Omega/ Aleph/Luatex for efficiency reasons. Also, such a change is not something to be undertaken lightly. I've done that for luatex and iirc there were a few small, subtle side-effects that took me entire days to hunt down. Definately a bad idea at last minute before texlive 2008, and therefore IMO probably not worth the trouble at all (for pdftex).
Or should the grouping levels instead use halfword? Or would you like to do it in a completely different way? This is a real life problem which affects building the PostgreSQL documentatin.
In any case, we should try running the test with aleph or luatex to be sure but I (at least half-)expect that the actual limit will not matter, and that it simply will never be large enough due to some form of recursion. I can try this tomorrow, will let you know then unless someone beats me to it. Best wishes, Taco
Frank Küster
There is a configuration variable nest_size level, but it doesn't seem to help in this case: The attached file gives an error
! TeX capacity exceeded, sorry [grouping levels=255].
although my texmf.cnf has nest_size=500.
I find it awfully hard to reliably trigger a semantic nest size overflow. The best I have been able to come up with was dak@lola:~$ tex This is TeX, Version 3.141592 (Web2C 7.5.6) **\def\x{\vbox\bgroup x\x}\x ! TeX capacity exceeded, sorry [semantic nest size=500]. <recently read> \bgroup \x ->\vbox \bgroup x\x <*> \def\x{\vbox\bgroup x\x}\x No pages of output. Transcript written on texput.log. But this only barely triggers, since 500 is less than 2*255, the grouping level limit. And I can't at the moment think of a way to get more than two semantic nests per grouping level. Can anybody think of a semantic nest without grouping apart from unrestricted hmode (which I use above)? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup wrote:
Frank Küster
writes: There is a configuration variable nest_size level, but it doesn't seem to help in this case: The attached file gives an error
! TeX capacity exceeded, sorry [grouping levels=255].
although my texmf.cnf has nest_size=500.
I find it awfully hard to reliably trigger a semantic nest size overflow. The best I have been able to come up with was
Can anybody think of a semantic nest without grouping apart from unrestricted hmode (which I use above)?
The example that was attached by Frank (or Stijn?) does just fine. As I suspected, the problem is a macro error, not an actual limit. With \tracingall, the run ends with the output below. We cannot fix this: the enlarging limits will just result in a "capacity exceeded" message with a higher counter. Best wishes, Taco ------------ \bm@command ...nd \z@ {\bm@gr@@p \boldmath {{b^c}} } \makebm #1$->\bm {#1} $ \bm@mchoice ... {\hbox {#1$\displaystyle \m@th #2$ }}{\hbox {#1$\textstyle \m... \bm@gr@@p ...fmmode \bm@mchoice #1{#2}{#2}{#2}{#2} \else \bfseries #1#2\fi \bm@command ...nd \z@ {\bm@gr@@p \boldmath {{b^c}} } \makebm #1$->\bm {#1} $ \bm@mchoice ... {\hbox {#1$\displaystyle \m@th #2$ }}{\hbox {#1$\textstyle \m... \bm@gr@@p ...fmmode \bm@mchoice #1{#2}{#2}{#2}{#2} \else \bfseries #1#2\fi \bm@command ...30049 ^{\bm@gr@@p \boldmath {{b^c}} } \makebm #1$->\bm {#1} $ \makelabel ...h {\makebm }\normalfont \bfseries #1 :} \sbox #1#2->\setbox #1\hbox {\color@setgroup #2 \color@endgroup } \@item ...i \fi \sbox \@tempboxa {\makelabel {#1}} \global \setbox \@labels \... l.11 \item[$a^{b^c}$] $a^{b^c}$ ! ==> Fatal error occurred, no output PDF file produced! ------------------
Taco Hoekwater
David Kastrup wrote:
Frank Küster
writes: There is a configuration variable nest_size level, but it doesn't seem to help in this case: The attached file gives an error
! TeX capacity exceeded, sorry [grouping levels=255].
although my texmf.cnf has nest_size=500.
I find it awfully hard to reliably trigger a semantic nest size overflow. The best I have been able to come up with was
Can anybody think of a semantic nest without grouping apart from unrestricted hmode (which I use above)?
The example that was attached by Frank (or Stijn?) does just fine.
But that's not without grouping as far as I can see, so it is not really different from what I had. If you put a line {{{{{{{{{{{{{{{{{{{{{ before the problem, then it will again bomb out with a grouping error instead. At least that is what I think I see when looking at the error message and context. In short: I don't see how one can trigger semantic nest errors when the semantic nest limit is more than twice the grouping limit (which it isn't right now). I might still be overlooking something, though. Already the single possibility to switch between semantic lists without a corresponding group switch that I can think of (basically \leavevmode/\par) escaped Knuth in the TeXbook Appendix D. As a result, the next edition (if we will see it) will have a quite simpler version of \removevboxes in it than previous ones. But there may be some rationale behind the current semantic nest size limit...
\bm@command ...nd \z@ {\bm@gr@@p \boldmath {{b^c}} } \makebm #1$->\bm {#1} $ \bm@mchoice ... {\hbox {#1$\displaystyle \m@th #2$ }}{\hbox {#1$\textstyle \m...
\bm@gr@@p ...fmmode \bm@mchoice #1{#2}{#2}{#2}{#2} \else \bfseries #1#2\fi \bm@command ...nd \z@ {\bm@gr@@p \boldmath {{b^c}} } \makebm #1$->\bm {#1} $ \bm@mchoice ... {\hbox {#1$\displaystyle \m@th #2$ }}{\hbox {#1$\textstyle \m...
\bm@gr@@p ...fmmode \bm@mchoice #1{#2}{#2}{#2}{#2} \else \bfseries #1#2\fi \bm@command ...30049 ^{\bm@gr@@p \boldmath {{b^c}} } \makebm #1$->\bm {#1} $ \makelabel ...h {\makebm }\normalfont \bfseries #1 :} \sbox #1#2->\setbox #1\hbox {\color@setgroup #2 \color@endgroup } \@item ...i \fi \sbox \@tempboxa {\makelabel {#1}} \global \setbox \@labels \... l.11 \item[$a^{b^c}$] $a^{b^c}$ ! ==> Fatal error occurred, no output PDF file produced!
-- David Kastrup
David Kastrup wrote:
Taco Hoekwater
writes:
David Kastrup wrote:
Can anybody think of a semantic nest without grouping apart from unrestricted hmode (which I use above)?
The example that was attached by Frank (or Stijn?) does just fine.
But that's not without grouping as far as I can see, so it is not really different from what I had. If you put a line {{{{{{{{{{{{{{{{{{{{{ before the problem, then it will again bomb out with a grouping error instead. At least that is what I think I see when looking at the error message and context.
In short: I don't see how one can trigger semantic nest errors when the semantic nest limit is more than twice the grouping limit (which it isn't right now).
I was still very much focused on the bug report when I wrote the above, so I misread your reply. You are almost certainly right about the nest>2*groups, just with maybe a small extra delta, like nest>2*groups+2 (because many functions push the semantic nest before the save stack). I do not want to spend the time (probably a lot of time) finding out the absolute truth, but I agree that a nest_size of 600 appears to make the error unreachable. Best wishes, Taco
Taco Hoekwater wrote:
You are almost certainly right about the nest>2*groups, just with maybe a small extra delta, like nest>2*groups+2 (because many functions push the semantic nest before the save stack). I do not want to spend the time (probably a lot of time) finding out the absolute truth, but I agree that a nest_size of 600 appears to make the error unreachable.
In (pdf)tex, that is. Not in Aleph|Omega|Luatex, and I am not sure about XeTeX. Best wishes, Taco
Taco Hoekwater
The example that was attached by Frank (or Stijn?) does just fine. As I suspected, the problem is a macro error, not an actual limit.
Ah, thank you. I didn't investigate this, since I assumed that the PostgreSQL documentation must have been built successfully on some other system.
With \tracingall, the run ends with the output below.
We cannot fix this: the enlarging limits will just result in a "capacity exceeded" message with a higher counter.
Hm, can you give me a short hint - what tells you that it's a macro error, and - where the error probably is? I can't quickly interpret the \tracingall output, (probably also because I usually just use single \tracingfoo commands). I guess I could figure out with some effort, but since you seem to have seen it already, please? TIA, Frank
Best wishes, Taco
------------ \bm@command ...nd \z@ {\bm@gr@@p \boldmath {{b^c}} } \makebm #1$->\bm {#1} $ \bm@mchoice ... {\hbox {#1$\displaystyle \m@th #2$ }}{\hbox {#1$\textstyle \m...
\bm@gr@@p ...fmmode \bm@mchoice #1{#2}{#2}{#2}{#2} \else \bfseries #1#2\fi \bm@command ...nd \z@ {\bm@gr@@p \boldmath {{b^c}} } \makebm #1$->\bm {#1} $ \bm@mchoice ... {\hbox {#1$\displaystyle \m@th #2$ }}{\hbox {#1$\textstyle \m...
\bm@gr@@p ...fmmode \bm@mchoice #1{#2}{#2}{#2}{#2} \else \bfseries #1#2\fi \bm@command ...30049 ^{\bm@gr@@p \boldmath {{b^c}} } \makebm #1$->\bm {#1} $ \makelabel ...h {\makebm }\normalfont \bfseries #1 :} \sbox #1#2->\setbox #1\hbox {\color@setgroup #2 \color@endgroup } \@item ...i \fi \sbox \@tempboxa {\makelabel {#1}} \global \setbox \@labels \... l.11 \item[$a^{b^c}$] $a^{b^c}$ ! ==> Fatal error occurred, no output PDF file produced!
------------------
-- Frank Küster Debian Developer (teTeX/TeXLive)
Frank Küster wrote:
Hm, can you give me a short hint
- what tells you that it's a macro error, and
That snippet was the actual error context so you have to read it upside down, and there is a bit of information missing. The general overview is: \makebm expands into something containing \bm that expands into something containing \bm@command that expands into something containing \bm@gr@@p that expands into something containing \bm@mchoice that expands into something containing \makebm ... (full circle)
- where the error probably is?
It seems \makebm is an internal macro of the bm package, and the document-level definition of \makebm to redefines that macro. Perhaps this is the result of a recent update of the bm package. At least that would explain why the documentation may have been run with errors in the past. There is a simple solution: use a different macro name for the in-document definition. Best wishes, Taco
The attached file gives an error Stijn, I'm not sure if you ever found the resolution. Using \loggingall on your source quickly shows there is, as Taco et al. surmised, an infinite loop. The log file ends with this: ... \bm@command ...nd \z@ {\bm@gr@@p \boldmath {{b^c}} } \makebm #1$->\bm {#1} $ \bm@mchoice ... {\hbox {#1$\displaystyle \m@th #2$ }}{\hbox {#1$\textstyle \m... \bm@gr@@p ...fmmode \bm@mchoice #1{#2}{#2}{#2}{#2} \else \bfseries #1#2\fi \bm@command ...30049 ^{\bm@gr@@p \boldmath {{b^c}} } \makebm #1$->\bm {#1} $ \makelabel ...h {\makebm }\normalfont \bfseries #1 :} \sbox #1#2->\setbox #1\hbox {\color@setgroup #2 \color@endgroup } \@item ...i \fi \sbox \@tempboxa {\makelabel {#1}} \global \setbox \@labels \... l.11 \item[$a^{b^c}$] $a^{b^c}$ You can see the loop, \makebm ends up calling itself. Evidently \makebm cannot be used in \everymath. Even a complete re-archiTeXture will not help :). Good luck, Karl
On Sun, 01 Jun 2008 01:55:24 +0200, Karl Berry wrote:
The attached file gives an error
Stijn, I'm not sure if you ever found the resolution.
[...]
You can see the loop, \makebm ends up calling itself.
Evidently \makebm cannot be used in \everymath. Even a complete re-archiTeXture will not help :).
The problem is this: When bm encounters a group such as happens in this case in the superscript, it will call \bm@mchoice defined thusly: \def\bm@mchoice#1#2#3#4#5{% \mathchoice{\hbox{#1$\displaystyle\m@th#2$}}% {\hbox{#1$\textstyle\m@th#3$}}% {\hbox{#1$\scriptstyle\m@th#4$}}% {\hbox{#1$\scriptscriptstyle\m@th#5$}}} Exiting and entering mathmode like this triggers \everymath and so our infinite recursion is started. Easiest remedy is to also tell \everymath to reset itself. \renewcommand*\descriptionlabel[1]{% \hspace\labelsep {\everymath{\everymath{}\makebm}\normalfont\bfseries #1:}% } -- Morten
Dear all,
thanks for tracking that down, and sorry for the long threads on that.
I am closing this bug. Stijn, I guess you should simply not use makebm
in everymath. If you actually want to do that, please reopen the bug,
and please retitle it to "make makebm usable in everymath", but you can
add a tag "wontfix" at the same time. We will not rewrite these macros.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
participants (6)
-
David Kastrup
-
Frank Küster
-
karl@freefriends.org
-
Morten Høgholm
-
Norbert Preining
-
Taco Hoekwater