11

I'm debugging the command tex of TeX Live 2019.

enter image description here

Shown as above, if you type:

./tex -ini

h


I&V


e

There will be a segment fault. Note that you need a h.tex under the same directory as tex and there is one character \ in h.tex.

My question is what does cmd I do? It seems it fails to open a file because there is an invalid sequence \&V after I. And what does cmd e do? I know It passes the file pointer to fclose() that failed to be initialized by I and the leads to the segment fault.

Thanks!

Svend Tveskæg
  • 31,033
潇洒张
  • 491
  • 1
    Welcome to TeX.SX! Donald already explained why the TeX errors happen. But to reproduce the segfault with tex (not -ini) you can write \? instead of \ and \&. More generally, the segfault happens if you are running TeX on a file, and press E in the menu while TeX is scanning the input of I. Interesting find! – Phelype Oleinik Jul 03 '20 at 03:33
  • It seems at first glance like a bug in TeX. A have no time for studying this issue in TeX sources now. If it is true bug then congratulations: you have found the bug in TeX 3.14159265. – wipet Jul 03 '20 at 06:58
  • @barbarabeeton May be you know the term when D. Knuth opens the folder with bug reports of TeX 3.14159265... – wipet Jul 03 '20 at 07:09

4 Answers4

7

Running TeX with the -ini flag means that you're running without any preloaded format. You don't get anything but primitive commands which means that \ and \& aren't defined. So that's why you're getting the errors. Do you really want to be running iniTeX?

i means insert the text following at the point that the error occurred. x is the usual quit command. e in theory will stop and then open an editor at the error point. I'm guessing this is missing some implementation/configuration which is why you're getting the segmentation fault. These are just some of the interactive error handling commands that TeX provides. See The TeXbook for more information about how these work. I've never really bothered with them. They made a lot of sense in the early 80s when computers were slow and compute time expensive but even by 1986 when I first started using TeX the program ran fast enough that it was generally more sensible to just use x to stop TeX, fix the error in the input file and continue.

Don Hosek
  • 14,078
  • The weird thing is that TeX seems to consistently segfault if you type e while reading the input of i... – Phelype Oleinik Jul 03 '20 at 03:22
  • Thanks a lot. But I'm a little bit confused about "i". Will "i" insert the text to the file h.tex? Or do you mean "i" just insert a text to a buffer? – 潇洒张 Jul 03 '20 at 03:59
  • No, it inserts the characters into the stream being read by the current run, so is not useful for fixing an error. It could be useful for diagnosing an error that you aren't sure of, but as DH says, it usually makes more sense to edit the input file and run TeX again. – Donald Arseneau Jul 03 '20 at 05:18
  • @DonaldHosek Did you get sucked into this quagmire by Coronavirus lockdowns too? – Donald Arseneau Jul 03 '20 at 05:21
  • 2
    @DonaldArseneau don't think of it as being sucked into a quagmire, think of it as being rescued from the primordial swamp that is c.t.t – David Carlisle Jul 03 '20 at 08:30
  • @DonaldArseneau It's more an occasional hobby for me. Every so often I think I should update and complete by LaTeX course materials to produce that book I'd started 30-some years ago. A lot has changed though so I don't know if I ever will. – Don Hosek Jul 03 '20 at 14:50
  • @DavidCarlisle there's also the indulging nostalgia factor too. I can picture myself sitting at my desk in Claremont, answering questions on c.t.t. on my homebuilt-PC running OS/2. – Don Hosek Jul 03 '20 at 16:29
  • @DavidCarlisle So we've graduated from the Archean to the Cambrian age. – Donald Arseneau Jul 03 '20 at 22:05
7

Congratulations, you have found the bug in TeX.

Edit I did deeper inspection about this issue when I returned from my vacation and I found: the bug is in the C implementation of TeX, not in the TeX itself (coded by D. Knuth). So, the following paragraph (given by me a few days ago) is not explicitly true:

The last revision of TeX (version 3.14159265) was done by D. Knuth in 2014, next revision will be in the end of 2020. If you send this bug-report you can get a check for a small piece in dollars by D. Knuth. Of course, this is true only if your bug report will be processed as real bug of TeX. How to do the bug report is described at here in section Errata.

Description of the bug: If we invoke an error (undefined \ in your example), then the I option is possible. If we use I option with a line with next error (undefined \& in your example) and the I line is not closed at this place (the V follows in your example) then this second error offers all options including E option. But using E option causes that TeX crashes, because the file name is zero in this case.

In detail: I option in § 84 of TeX web runs the code from § 87 where the procedure begin_file_reading is processed. This procedure is in § 328 and here is: name := 0. The name is macro defined in § 302: name = cur_input.name_field. Now, we can return to § 84 where the E option is solved. It creates the file name (which may be sent to an editor) from input_stack[base_ptr].name_field but this is the same as cur_input.name_field and it was set to zero. We have no file name here but zero. TeX implementation based on C crashes with segmentation fault because we want to open the file with buggy file name.

Edit: When I did experiments with tex.web code and I deactivated the system dependent code given after E option then the correct answer is here: You want to edit file <correct name> at line <correct number>. The bug is in the lib/texmfmp.c at line 2579 where the opened files are closed and the maximal index of opened files are read from inopen global variable. This variable is incremented when I option is used but no new file is opened in such case. So, we cannot close non-existent file in lib/texmf.c. Knuth says in §304: "The global variable in_open is equal to the value of the highest non-token-list level." It means that it is not always the number of currently opened files. Knuth's code and his comments in the code are correct here, bug is in the system dependent implementation.

wipet
  • 74,238
  • At the point of the first error message, \jobname has been set to h. – egreg Jul 03 '20 at 13:07
  • @egreg the file name h is irrelevant. You can insert \bla in your document (the name of the document and the format are irrelevant). When the prompt about undefined \bla occurs then inset i\buff X. When the prompt about undefined \buff occurs then insert e. The result is segmentation fault. – wipet Jul 03 '20 at 13:13
  • Maybe you can make it clear in your answer. – egreg Jul 03 '20 at 13:29
  • But it crashed on fclose() with uninitialized file pointer as the argument. In this case there is only one file: h.tex. But inopen was 2 when it tried to close all files. So it tried to close inputfile[1] and inputfile[2] in a for loop and inputfile[2] was uninitialized. – 潇洒张 Jul 03 '20 at 14:23
  • The fclose() is part of system dependent implementation. The core of the bug report is that tex.web in §84 suggests to open file with buggy file name in its message "You want to edit file ... at line ...". This message is re-implemented using system depending tools, especially in C: the file with the name given by tex.web code is tried to be opened using calledit() function. – wipet Jul 03 '20 at 14:43
  • What does § mean? – 潇洒张 Jul 03 '20 at 15:37
  • @潇洒张 You can download tex.web from internet and apply weave tex.web. The file tex.tex is created. Then use tex tex.tex. The file tex.dvi is created. You can see here, it is commented and documented source of TeX and it is divided to numbered paragraphs, in short to §. – wipet Jul 03 '20 at 15:49
  • I'm confused. According my observation, begin_file_reading() was called twice. The first time is after receiving "h". I can understand here because h.tex is a file. But the second time is after receiving "i", which file was trying to be opened this time? – 潇洒张 Jul 03 '20 at 15:50
  • The reading from lines from file or from terminal is done using stack array. It is described in detail in the § 300 -- 310 in tex.web. – wipet Jul 03 '20 at 15:57
  • 1
    @潇洒张 I corrected the term of bug report: the end of this year. Please, tell me if you prepare this bug report. If no, then I will try to do it. But you found this bug, this is much more correct if the honor will go to you. I have only analyzed this big from technical point of view. But I wouldn't think of trying the E option in the context of I option. – wipet Jul 03 '20 at 20:24
  • In your answer you write: "It creates the file name (which may be sent to an editor) from input_stack[base_ptr].name_field but this is the same as cur_input.name_field and it was set to zero." I'm sorry, but this is just wrong: input_stack[base_ptr].name_field is not the same as cur_input.name_field (at the point where file name is sent to an editor). Please fix your answer. – Igor Liferenko Oct 26 '23 at 01:17
5

Original poster: as with your other report ... if you ever see this, please email me, karl at tug.org, so we can give you proper credit in our report to Don Knuth. (We believe there is a bug in tex.web as well as in web2c; the tex.web code can be induced to print a bogus filename in the "You want to edit ..." message.)

Regarding begin_file_reading, it is, shall we say, suboptimally named. What it really does is "begin a level of input" - either from a file or from terminal interaction.

I just committed a fix (hopefully) for this to TeX Live, r55857 (http://tug.org/svn/texlive/trunk/Build/source/texk/web2c/lib/texmfmp.c?r1=53078&r2=55857&pathrev=55857). It involves having to look at all elements of input_stack[] to discern whether a given entry in input_file[] is actually a file, or a non-file resulting from terminal interaction. Before, we simply closed everything in input_file[], but that was wrong.

Regarding "the end of this year" - please send any and all Knuthian bug reports to me or tex-k at tug.org as soon as possible! Do not wait for December 31. My unofficial deadline is November 1. All reports have to be vetted before they go into the pile for Knuth, and it takes time. More info: https://tug.org/texmfbug.

Thanks to all.

Karl Berry
  • 2,102
0

Apply this change to original tex.web and you will see that there is no bug in TeX:

@x
@.You want to edit file x@>
  slow_print(input_stack[base_ptr].name_field);
  print(" at line "); print_int(line);
@y
@.You want to edit file x@>
  slow_print(input_stack[base_ptr].name_field);
  print(" which has string number ");
print_int(input_stack[base_ptr].name_field);
@z

The output:

You want to edit file h.tex which has string number 1346

(i.e., input_stack[base_ptr].name_field is not zero)

Therefore, the relevant change entry is totally useless and serves no purpose:

431. Don't exit to editor if no input file is at the bottom line
(Xiaosa Zhang, 03 July 2020)
@x module 84
"E": if base_ptr>0 then
@y
"E": if base_ptr>0 then if input_stack[base_ptr].name_field>=256 then
@z
@x module 85
if base_ptr>0 then print("E to edit your file,");
@y
if base_ptr>0 then if input_stack[base_ptr].name_field>=256 then
  print("E to edit your file,");
@z

(all the calamities are due to web2c)

Igor Liferenko
  • 7,063
  • 2
  • 14
  • 47