[ptex] 大量のフォント読込で Segmentation fault

[aminophen]

大量のフォントを読込でメモリを消費すると，ptex が Segmentation fault: 11 する場合があります。

私のところでは r64841 からビルドした ptex で toomany.tex.txt で落ちましたが，同じソースでは uptex, eptex, euptex は落ちません。

! Font \mmmmcccxlviii=bsmilp49 not loaded: Not enough room left.

といった上限に引っかからずに落ちるには，かなり微妙な占有状況が必要なようです。

[aminophen]

おっと，そもそも ptex ではフォント数の上限が 256 みたい？？？？？

%#!ptex -ini
\tracingonline1 \tracingoutput1 \showboxdepth10000 \showboxbreadth10000 
\expandafter\font\csname\romannumeral1\endcsname andk-Bold-tlf-ly1 \csname\romannumeral1\endcsname
\expandafter\font\csname\romannumeral2\endcsname andk-Bold-tlf-ot1 \csname\romannumeral2\endcsname
\expandafter\font\csname\romannumeral3\endcsname andk-Bold-tlf-sc-ly1--base \csname\romannumeral3\endcsname
\expandafter\font\csname\romannumeral4\endcsname andk-Bold-tlf-sc-ly1 \csname\romannumeral4\endcsname
\expandafter\font\csname\romannumeral5\endcsname andk-Bold-tlf-sc-ot1--base \csname\romannumeral5\endcsname
...
\expandafter\font\csname\romannumeral254\endcsname Comfortaa-Regular-T2C-Slanted--base \csname\romannumeral254\endcsname
\expandafter\font\csname\romannumeral255\endcsname Comfortaa-Regular-T2C-Slanted \csname\romannumeral255\endcsname
\expandafter\font\csname\romannumeral256\endcsname Comfortaa-Regular-T2C \csname\romannumeral256\endcsname
\expandafter\font\csname\romannumeral257\endcsname Comfortaa-Regular-TS1--base \csname\romannumeral257\endcsname
\expandafter\font\csname\romannumeral258\endcsname Comfortaa-Regular-TS1-Slanted--base \csname\romannumeral258\endcsname
\expandafter\font\csname\romannumeral259\endcsname Comfortaa-Regular-TS1-Slanted \csname\romannumeral259\endcsname
\expandafter\font\csname\romannumeral260\endcsname Comfortaa-Regular-TS1 \csname\romannumeral260\endcsname
\expandafter\font\csname\romannumeral261\endcsname Comfortaa-Regular-X2--base \csname\romannumeral261\endcsname
a\end

Overfull \hbox (6.76799pt too wide) in paragraph at lines 262--262
[]\v a

\hbox(6.01099+0.0)x0.0
.\hbox(0.0+0.0)x0.0
.\displace 0.0
.\v a
.\penalty 10000
.\glue(\parfillskip) 0.0
.\glue(\rightskip) 0.0

Completed box being shipped out [0]
\vbox(0.0+0.0)x0.0, yoko direction
.\glue(\topskip) 0.0
.\hbox(6.01099+0.0)x0.0
..\hbox(0.0+0.0)x0.0
..\displace 0.0
..\v a
..\penalty 10000
..\glue(\parfillskip) 0.0
..\glue(\rightskip) 0.0
.\hbox(0.0+0.0)x0.0

 )

なぜかフォント \v つまり andk-Bold-tlf-sc-ot1--base で出力される…。

[h-kitagawa]

pTeX では max_quarterword=255 なのが，e-pTeX, (e-)upTeX では max_quarterword=65535 であることが影響していそうな気がします（後で texmfmem.h の中身を調べます）．

[h-kitagawa]

pTeX では max_quarterword=255 なのが，e-pTeX, (e-)upTeX では max_quarterword=65535 であることが影響していそうな気がします（後で texmfmem.h の中身を調べます）．

あたりでした．まず TeX 側でノード p のフォントを示す font(p) は，C 言語では mem [p ].hh.b0 と書かれています．

そこで texmfmem.h を見たところ，「1 つのノード」を表す型は次のようになっています（改行位置を改めとか，不要な部分を削除するなどしています）

typedef union {
...
  twohalves hh;
...
} memoryword;
#define b0 u.B0

欧文 TeX では

typedef union {
  struct {
    short B1, B0;
  } u;
} twohalves;

となり，mem [p ].hh.b0 の型は short です．

一方 pTeX 系では

typedef union {
  struct {
    quarterword B1, B0;
  } u;
} twohalves;

となり，mem [p ].hh.b0 の型は quarterword です．

pTeX ではquarterword は unsigned char の別名，e-pTeX, (e-)upTeX ではquarterword は unsigned short の別名なので，全部まとめると pTeX p4.x だけフォント数の上限が256（欧文 TeX ですらそれ以上使える）ことになります．

解決策は次のどちらかです：

• pTeX でも max_quarterword = 256 にする
• texmfmem.h の最初の #if で pTeX 判定を外す（e-pTeX, (e-)upTeX の判定は残す）

81 への対応 (pTeX p4.0.0) で埋め込まれてしまったバグですが，なぜこうしてしまったのかは覚えていません……．

[aminophen]

調査ありがとうございます。確かに TL2021 の ptex (p3.9.0) では上限に引っかかりませんでした…。意図せず pTeX-p4.0.0 でフォント数上限が 256 に減っていたのですね。元どおり使えるようにするには

texmfmem.h の最初の #if で pTeX 判定を外す（e-pTeX, (e-)upTeX の判定は残す）

だと理解しますが b7665e0b46452dea9865a98cbebe482f899a5909 での texmfmem.h の条件文変更を元に戻すと何か不都合があるのか試します。

[edit] いやでも e-(u)pTeX が問題ないので「pTeX は廃止してしまう」の方が手っ取り早い気がする…。

[aminophen]

https://github.com/texjporg/tex-jp-build/commit/b7665e0b46452dea9865a98cbebe482f899a5909 では str_pool に 0x00〜0x1ff を保存できるようにするため unsigned short 型に変更しているようなのですが，このとき mem は変更しなくてもよかった，ということのように思います。

[aminophen]

もう一案の「条件文は変更後のママ，pTeX で max_quarterword="FFFF にした場合」も

• This can't happen のメッセージが 256 span ではなくなる
  • → XeTeX では「confusion("too many spans")」に変更されている

くらいの影響で済むように思います。どちらがよいでしょう。

[aminophen]

条件文は変更後のママ，pTeX でmax_quarterword="FFFF にした場合

こちらの方が pTeX ←→ upTeX/e-pTeX/e-upTeX の差分を減らせるので https://github.com/texjporg/tex-jp-build/commit/4e9dafce9818909344e3fc5e4a0d6f5ec008c761 で試しています。

[aminophen]

大丈夫そうなのでマージしました。r64914