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 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 -----------------------------------------------------------------

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.

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 -----------------------------------------------------------------

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