Hi, the following causes a segfault here (TL20): \pdfadjustinterwordglue1 \unhbox0 \kern1pt \ % \end Best, -- Robert
Hi Robert, Confirmed here; it seems that pdftex.web L.3779 @d auto_kern == explicit is the culprit. In your proposed MWE, when the function adjust_interword_glue() is called, the tail node is \kern1pt thus (type=kern_node) and (subtype=explicit). However, "@d auto_kern == explicit" is set, it falls through the following conditions. else if (type(p) = kern_node) and (subtype(p) = auto_kern) and (save_tail <> null) then When I change that line to @d auto_kern == 3 {|acc_kern| + 1} the problem is gone. I'm not sure whether there is some side effect. Hironobu Yamashita
Hi Robert & Hironobu, On Tue, May 26, 2020 at 3:25 PM Hironobu Yamashita < h.y.acetaminophen@gmail.com> wrote:
Hi Robert,
Confirmed here; it seems that pdftex.web L.3779
@d auto_kern == explicit
is the culprit.
In your proposed MWE, when the function adjust_interword_glue() is called, the tail node is \kern1pt thus (type=kern_node) and (subtype=explicit). However, "@d auto_kern == explicit" is set, it falls through the following conditions.
else if (type(p) = kern_node) and (subtype(p) = auto_kern) and (save_tail <> null) then
When I change that line to
@d auto_kern == 3 {|acc_kern| + 1}
the problem is gone. I'm not sure whether there is some side effect.
I can confirm that Hironobu's analysis is correct. Thank you for your help. Regards, Thanh
On 5/26/2020 3:25 PM, Hironobu Yamashita wrote:
Hi Robert,
Confirmed here; it seems that pdftex.web L.3779
@d auto_kern == explicit
is the culprit.
In your proposed MWE, when the function adjust_interword_glue() is called, the tail node is \kern1pt thus (type=kern_node) and (subtype=explicit). However, "@d auto_kern == explicit" is set, it falls through the following conditions.
else if (type(p) = kern_node) and (subtype(p) = auto_kern) and (save_tail <> null) then
When I change that line to
@d auto_kern == 3 {|acc_kern| + 1}
the problem is gone. I'm not sure whether there is some side effect.
That all depends on whether the machinery checks for a subtype ... when I look at the pdftex.web source (on the web that is) i see for instance that the line break code does some check: kern_node: if subtype(s)<>explicit then goto done So when you change subtype 2 to 3 that will behave different. Now, I have no clue what this interword features does but you enter this code while (link(r) <> null) and (link(r) <> p) do r := link(r); if (link(r) = p) then set_char_and_font(r); and there should probably be checks there, like while (r) and (link(r) <> null) and (link(r) <> p) do r := link(r); if (r) and (link(r) = p) then set_char_and_font(r); so that you don't access null nodes ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Hi Hans,
That all depends on whether the machinery checks for a subtype ...
True; I will take a look at all checks for subtype of kern_node. (It's too late at night in Japan here, maybe tomorrow)
there should probably be checks there, so that you don't access null nodes
Not necessary, as it starts with r:=save_tail and save_tail is already known to be non-null. Thanks, Hironobu -- ---- 山下 弘展 (Hironobu Yamashita) e-mail: h.y.acetaminophen@gmail.com
Hi Hironobu,
True; I will take a look at all checks for subtype of kern_node.
Thanh changed pdftex.web upstream by your finding : https://www.tug.org/svn/pdftex/branches/stable/ Please check. Many thanks, Akira
On 5/27/2020 9:21 AM, Hironobu Yamashita wrote:
Hi,
Thanh has committed a fix to the pdftex repo (r828).
Thanks. I think the additions of (r<>null) are no-op thus can be removed. (It does no harm, though.)
if there is a loop over a list you want to quit when you run out of items; vlink(n) doesn't do a check if n equals null, it accesses a field in a node (and likely the next field in a null node is some weird random value which then brings you to whatever memory is related etc)
I wonder if there is still some possibility of uninitialized save_tail (which is 0, not null). null is actually 0 in tex
when used this way save-tail is just a number pointing to a slot in a memory array where a node blob (of whatever length) sits Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Hi Hans,
Thanks. I think the additions of (r<>null) are no-op thus can be removed. (It does no harm, though.)
if there is a loop over a list you want to quit when you run out of items ...
Of course I know but still I think the additions of (r<>null) are no-op. Reasons:
else if (type(p) = kern_node) and (subtype(p) = auto_kern) and (save_tail <> null) then
Here save_tail is already known to be non-null, so ...
begin r := save_tail;
Here r is non-null.
while (link(r) <> null) and (link(r) <> p) do
Inside this loop link(r) is non-null, so ...
r := link(r);
Here again r is non-null.
I wonder if there is still some possibility of uninitialized save_tail (which is 0, not null).
null is actually 0 in tex
But from my observation of the Robert's MWE, save_tail was 0 but not equal to null. That's why it accidentally fell through. Hironobu
Thanks. I think the additions of (r<>null) are no-op thus can be removed. (It does no harm, though.) I wonder if there is still some possibility of uninitialized save_tail (which is 0, not null). Thanh also committed some tests in <pdftex>/tests/14-*. Maybe you could add or change the tests to exhibit the uninitialized save_tail problem? I defer on any changes to you and Thanh ... --thanks much, karl.
Hello,
Thanh has committed a fix to the pdftex repo (r828).
It seems that save_tail can be a node outside the current list.
I used the attached patch (pdftex_debug.diff) against r828
to print the node number, and processed following aiwg.tex.
%========
% aiwg.tex (attached)
\pdfadjustinterwordglue1 \pdfappendkern1 \knaccode\font`\f=200
\leavevmode A%
\setbox2\hbox{1f}\setbox0\hbox{2f\ }%
\unhbox2\
\end
%========
I got the following output, which indicates save_tail (4994983) is not
on the current list.
SAVE_TAIL: 4994981
node: 4994986 char_node
node: 824 0
node: 4994987 char_node A % <== from l.2
node: 4994985 char_node 1 % <== from \unhbox2
node: 4994983 char_node f % <== from \unhbox2
node: 820 11 % <== from \unhbox2
--
Hironori KITAGAWA
On 5/28/2020 2:35 PM, Hironori KITAGAWA wrote:
Hello,
Thanh has committed a fix to the pdftex repo (r828).
It seems that save_tail can be a node outside the current list.
I used the attached patch (pdftex_debug.diff) against r828 to print the node number, and processed following aiwg.tex. %======== % aiwg.tex (attached) \pdfadjustinterwordglue1 \pdfappendkern1 \knaccode\font`\f=200 \leavevmode A% \setbox2\hbox{1f}\setbox0\hbox{2f\ }% \unhbox2\ \end %========
I got the following output, which indicates save_tail (4994983) is not on the current list.
SAVE_TAIL: 4994981 node: 4994986 char_node node: 824 0 node: 4994987 char_node A % <== from l.2 node: 4994985 char_node 1 % <== from \unhbox2 node: 4994983 char_node f % <== from \unhbox2 node: 820 11 % <== from \unhbox2 maybe the appender should check of the preceding node is a glyph
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Hi, Please find the attached patches (for pdftex r828 and tl svn) * Globally initialize save_tail:=null, to ensure that it is never referenced before initialized. I cannot make any tests to exhibit the uninitialized save_tail problem, but this change would make it safer. Note: (pdf)tex.web sets
@d null==min_halfword and @d min_halfword==0 In this case, uninitialized save_tail (= 0) accidentally equals to null. However, after tex.ch changes @d min_halfword==-@"FFFFFFF In this case, uninitialized save_tail (= 0) is not null so the test inside adjust_interword_glue() will not work. else if (type(p) = kern_node) and (subtype(p) = auto_kern) and (save_tail <> null) then
* Remove no-op (r<>null) checks; already explained in my previous mail. The save_tail outside the current list, reported by Hironori, still remains but it should be regarded as another issue. I think my patches are enough to solve the segfault issue which should be corrected asap. Best, Hironobu
Just to close the loop on this: Please find the attached patches (for pdftex r828 and tl svn) As you've probably seen, Thanh and Akira and I between us have committed it to both TL and pdftex. I synced the two repositories, hopefully without losing anything. Thanks much. -k
Subject: Re: [NTG-pdftex] segfault with \pdfadjustinterwordglue Thanh has committed a fix to the pdftex repo (r828). I'll push it over to TeX Live (so that Akira can distribute it ...) soon,unless someone else gets there first :). Robert, thanks for the report (again). --best, karl.
participants (7)
-
Akira Kakuto
-
Hans Hagen
-
Hironobu Yamashita
-
Hironori KITAGAWA
-
Karl Berry
-
Robert
-
The Thanh Han