Reloading the font name database hangs with `LXGWNeoXiHei.ttf` installed

[gucci-on-fleek]

Earlier today, someone on the TeX Live list reported that running luaotfload-tool --update with LXGWNeoXiHei.ttf installed hangs forever. ConTeXt has the exact same behaviour. Even if it's the font itself that's buggy/broken, I'd argue that luaotfload shouldn't enter an infinite loop when trying to load it.

[gucci-on-fleek]

Hans doesn't want to fix this in ConTeXt, so there's probably nothing that you can do here, unless you want to add a per-font timeout (which might be a good idea regardless).

[zauguin]

unless you want to add a per-font timeout (which might be a good idea regardless).

It would be a good idea especially during font loading, but implementing a timeout here is tricky since we don't have a nice way of reliably gaining execution. When we know where the holdup is we could do regular checks, but that can only help with known issues.
If we had access to the debug library we could use hooks for this, but having a timeout which only works with shell-escape would be of very limited usefulness. I have ideas how to maybe make it a bit faster, but currently this has rather low priority given that it "only" happens during database building and that the particularly bad font is rolled back for now.

[gucci-on-fleek]

If we had access to the debug library we could use hooks for this

We can always ask Luigi to re-enable debug.sethook() for TL27, but this will only help if the code is getting stuck in Lua and not C. (It presumably is stuck in Lua, but I haven't traced it yet)

[MacLotsen]

Having a similar issue on Ubuntu 24.04 (and not 22.04). It ate all my 64Gb of RAM. Also, the verbose output is minimal:

luaotfload | db : Updating the font names database forcefully.
luaotfload | db : Scanning TEXMF for fonts...
luaotfload | db : Scanning system fonts...
luaotfload | db : Scanning 6515 collected font files ...

Even after removing the symlinks from /usr/share/fonts to /usr/share/texmf... didn't decrease the number of files collected.

After adding option -vvvv I detected it's haning on the same font:

luaotfload | db : Loading font ..ts/truetype/public/lxgw-fonts/LXGWNeoXiHei.ttf

The TeX Live 2026 bundled font texmf-dist/fonts/truetype/public/lxgw-fonts/LXGWNeoXiHei.ttf appears malformed or at least triggers parser failure. On my system, otfinfo -i reports OTF data for 'vmtx' out of range, and luaotfload-tool -u -f consumes extreme memory. Reverting to the TeX Live 2025 version avoids the problem or removing the package: tlmgr remove --force lxgw-fonts.

[zauguin]

We can always ask Luigi to re-enable debug.sethook() for TL27, but this will only help if the code is getting stuck in Lua and not C. (It presumably is stuck in Lua, but I haven't traced it yet)

We could, but allowing sethook might be risky. It allows gaining execution in weird situations, that can easily lead to security issues.

[fragrans]

it stucks on Sarasa.

https://github.com/be5invis/Sarasa-Gothic

[gucci-on-fleek]

it stucks on Sarasa.

Probably unrelated; that font is absolutely ginormous

$ du --human-readable Sarasa-SuperTTC.ttc
792M	Sarasa-SuperTTC.ttc

so I'm guessing that it's not completely frozen, but just taking a really long time.

[fragrans]

yes, you are right. i tried again.
it took more than one hour, 65 min exactly, to finish.
so, its unusable for this kind of font files.
And CJK font files are really big.

[gucci-on-fleek]

And CJK font files are really big

They're big-ish, but not this big usually. I believe that Noto has pretty good CJK glyph coverage, and it's only 2% of Sarasa's size:

$ du --human-readable /usr/local/texlive/2026/texmf-dist/fonts/opentype/google/notocjksc/NotoSerifCJKsc-Regular.otf
23M	/usr/local/texlive/2026/texmf-dist/fonts/opentype/google/notocjksc/NotoSerifCJKsc-Regular.otf

And luaotfload has no problems loading Noto. I also have Unifont installed (which has a ton of glyphs too), and that loads without any issues.

I agree that it would be good if luaotfload supported loading Sarasa, but that should probably be discussed in #312 instead of here (although it's fairly unlikely to be implemented since I can already guess how Hans would respond to the feature request)

[u-fischer]

so, its unusable for this kind of font files.

Well the question is how much time it needs the second time, now that the database knows it.