[tex-k] segfault in texlive2020 pdftex/luatex/xetex/ptex/...
Ken Brown
kbrow1i at gmail.com
Mon Jun 1 03:42:31 CEST 2020
On 5/31/2020 5:15 PM, Karl Berry wrote:
> [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.
I can build tex so that it uses a bigger stack if that seems desirable, by
passing a suitable linker argument. (I do that in my build of emacs for
Cygwin.) It's also possible for anyone to do that with their own executable.
'ulimit -s' doesn't work on Cygwin, but there's a 'peflags' utility that does.
[Try 'peflags -h' for details.] Examples:
$ cp /usr/bin/emacs-nox.exe example.exe
$ peflags -x example.exe
example.exe: stack reserve size : 8388608 (0x800000) bytes
$ peflags -x0x900000 example.exe
example.exe: stack reserve size : 9437184 (0x900000) bytes
> 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
Emacs has some code that tries to detect stack overflow and recover enough to
allow the user to save his/her work and exit. I don't remember the details, but
I don't see any need to do this for tex, since the user doesn't lose any work
just because tex has exhausted its stack.
I'm happy to do whatever Cygwin users want if the default stack size seems too
small.
Ken
More information about the tex-k
mailing list.