[tex-k] Crash (segmentation fault) from endwrite token

tttex at mailbox.org tttex at mailbox.org
Sat Jul 30 23:10:06 CEST 2022


If I am not mistaken, only disallowing expansion of \endwrite is not sufficient to avoid all crashes. An \ifx might for example attempt to access the non-existing reference count of the token list of \endwrite while avoid both outer detection and expansion. The following variant of the code still leads to a crash on my machine while avoiding expansion suppression of \endwrite:


Would it be a solution to change the definition of the `equiv' of \endwrite in module 1369 from `null' to `null_list'  (as is done for frozen_end_template)?


> Karl Berry <karl at freefriends.org> hat am 17.07.2022 02:45 CEST geschrieben:
> Subject: [tex-k] Crash (segmentation fault) from endwrite token
>     This report is from "user202729" on StackExchange 
>     [ ... https://tex.stackexchange.com/questions/609423 ]
> Thanks for passing that on. DRF proposed this fix, to simply disallow
> \noexpand\endwrite, which seems to be the original source of the problem.
> @x [25.369] l.7717 - disallow \noexpand\endwrite
> if t>=cs_token_flag then
> @y
> if (t>=cs_token_flag)and(t<>end_write_token) then
> @z
> I committed it to TL in r63916, and wrote user202729, and posted on
> tex.sx, and added it to newbug.html at
> https://tug.org/texmfbug/newbug.html#B155endwrite. First code bug since
> the tune-up ...
> If any of the other nefarious TeX examples in that tex.sx question seem
> like they might be bugs, let me know? I surmise if there is no crash,
> Knuth's answer would be "you're getting what you deserve", but hard to
> say for sure.
> Thanks,
> Karl

More information about the tex-k mailing list.