Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
aminophen opened this issue Oct 29, 2022 · 8 comments
Closed

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

aminophen opened this issue Oct 29, 2022 · 8 comments
Labels

Comments

@aminophen
Copy link
Member

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

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

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

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

@aminophen aminophen added the bug label Oct 29, 2022
@aminophen
Copy link
Member Author

おっと,そもそも 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
Copy link
Member

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

@h-kitagawa
Copy link
Member

h-kitagawa commented Oct 29, 2022

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
Copy link
Member Author

aminophen commented Oct 29, 2022

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

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

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

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

@aminophen
Copy link
Member Author

b7665e0 では str_pool に 0x00〜0x1ff を保存できるようにするため unsigned short 型に変更しているようなのですが,このとき mem は変更しなくてもよかった,ということのように思います。

@aminophen
Copy link
Member Author

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

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

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

@aminophen
Copy link
Member Author

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

こちらの方が pTeX ←→ upTeX/e-pTeX/e-upTeX の差分を減らせるので 4e9dafc で試しています。

@aminophen
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants