[tex-k] segfault in texlive2020 pdftex/luatex/xetex/ptex/...

[Karl Berry]

[Ken: see thread at https://tug.org/pipermail/tex-k/2020-May/003178.html]

    \def\z{\number\z}\z

As others have said, it is evidently a matter of running out of stack
space at runtime. That input results in a loop among
..
#174440 0x0000000000420ad2 in getxtoken () at tex0.c:6935
#174441 0x0000000000421f1b in scanint () at tex0.c:7675
#174442 0x0000000000423352 in convtoks () at tex0.c:8361
#174443 0x000000000042085b in expand () at tex0.c:6829
#174444 0x0000000000420ad2 in getxtoken () at tex0.c:6935

It seems to me that any language with recursive macro expansion is going
to have the same problem.

On my system at home, expand_depth=45000 is large enough to cause the
sigsegv (after some 174,444 stack frames, as shown above).

    on cygwin, [...]
    tex --cnf-line="expand_depth=5382" segv
    [other numbers on other platforms]

I surmise it is not a matter of platform x vs. platform y, but the
amount of available memory for the stack on the current machine, and/or
any limits set.  ulimit -s to get/set that value (8192 for me). It's not
clear to me that Ken has any way to affect the outcome in the Cygwin
build of TL.

As far as I could discern, there is no good way for the code to detect
that the stack is going to overflow (or any good place to check --
before each function call? No :). The best answer I found involves
calling getrlimit() and guessing at a safety margin: see the last answer
at https://stackoverflow.com/questions/35223114. This code does not look
like anything I want to inject into TeX, and I don't think it (or
anything) can guarantee to avoid the sigsegv

We could decrease the initial expand_depth to (say) 5000 instead of the
current 10000 so that the TeX error is more likely to happen instead of
the crash. Given sufficiently small memory, it will still happen,
though. So I'm not sure it's worth doing? --thanks, karl.