TeX Output segmentation fault on minimal document on TeXLive 2016 pretest

[jfbu]

I am on TeXLive pretest, updated as of today. On compiling LaTeX minimal document:

\documentclass{article}
\usepackage{fontspec}
\begin{document}
Hello
\end{document}

I get

luaotfload | db : Font names database not found, generating new one.
luaotfload | db : This can take several minutes; please be patient.
TeX Output segmentation fault: 11 at Mon Apr 11 10:08:00

I attach full console output:
testlualatex-11avril2016-output.txt

Perhaps there is mismatch of luaotfload version and used LuaTeX ?

[eg9]

After running luaotfload-tool -u -vvv I discovered that the segmentation fault happened when processing LastResort.ttf.

luaotfload | db : Loading font /System/Library/Fonts/LastResort.ttfSegmentation fault: 11

I added the font to the black list

/usr/local/texlive/2016/texmf-dist/tex/luatex/luaotfload/luaotfload-blacklist.cnf

so that now it contains

spltfgbd.ttf
spltfgbi.ttf
spltfgit.ttf
spltfgrg.ttf
LastResort.ttf

and rerun luaotfload-tool -u -vvv.

After that, the example compiled successfully. The font appeared in the black list in TeX Live 2013, but not in the 2014 and 2015 releases.

[jfbu]

Confirmed. I found the same, added LastResort.tff as indicated to the black list then again

luaotfload-tool -u -vvv

and the example compiles.

I don't have luaoftload but only luaotfload-tool appearing among the repertory /Library/TeX/texbin. In fact it is also because I keep forgetting what is the syntax that I posted on tl list and here, but I will try to recall that I only need to checkout the texbin repertory. Then luaotfload-tool --help has sufficient information.

To be noted:

$ luaotfload-tool --version

luaotfload-tool:
        Luaotfload font management and diagnostic utility.
        License: GNU GPL v2.0.
        Report problems to <https://github.com/lualatex/luaotfload/issues>

luaotfload-tool version: "2.6"
Revision: "2f2f16ec56510dc000302297aca4098a17eb7f5d"
Lua interpreter: stock; version "Lua 5.2"/Library/TeX/texbin/luaotfload-tool:310: bad argument #2 to 'stringformat' (number expected, got nil)

note the error message at the end. But luaotfload-tool --help suggests luaotfload-tool --version is correct syntax.

[phi-gamma]

···<date: 2016-04-11, Monday>···<from: jfbu>···

$ luaotfload-tool --version

luaotfload-tool:
Luaotfload font management and diagnostic utility.
License: GNU GPL v2.0.
Report problems to https://github.com/lualatex/luaotfload/issues

luaotfload-tool version: "2.6"
Revision: "2f2f16ec56510dc000302297aca4098a17eb7f5d"
Lua interpreter: stock; version "Lua 5.2"/Library/TeX/texbin/luaotfload-tool:310: bad argument #2 to 'stringformat' (number expected, got nil)

note the error message at the end. But `luaotfload-tool --help`
suggests ` luaotfload-tool --version` is correct syntax.

This has already been fixed: phi-gamma@15753d8

See also: http://thread.gmane.org/gmane.comp.tex.luatex.user/5743

Best,
Philipp

[phi-gamma]

···<date: 2016-04-11, Monday>···<from: eg9>···

After running luaotfload -u -vvv I discovered that the segmentation fault happened when processing LastResort.ttf. I added it to the black list

/usr/local/texlive/2016/texmf-dist/tex/luatex/luaotfload/luaotfload-blacklist.cnf

and rerun luaotfload -u -vvv.

After that, the example compiled successfully.

We removed LastResort.ttf a while back due to rumors that it
worked well with Luatex, see commit c3b8039
I gather it’s a non-free font so it’s hard to test it
systematically.

If you could run a debug build in Valgrind and report back that
might be helpful.

In any case, the report is moot since we’re in the process of
ditching the Fontforge loader for good. For the 2.7 release, the
goal is make it entirely optional, for use as reference until
Luatex 1.0 comes out. Thus any effort toward fixing FF are a
waste of energy at this point. Just blacklist broken fonts for
the time being and hope we’ll arrive at something useable by the
end of the pretest ;)

Best,
Philipp

[aminophen]

I'm having the same problem with my OS X 10.11.3 (El Capitan), and found this issue.

The blacklist before commit c3b8039 says

% Takes ages to load
LastResort.ttf % a MacOSX font, but also available for free from unicode.org 

However, it seems that LastResort.ttf in Mac OS X 10.11.3 is different from the one available from unicode.org. Actually, LastResort.ttf from unicode.org does not cause segfault problem, and the size is also different.

"LastResort.ttf" in OS X /System/Library/Fonts directory:

-rw-r--r--  1 root  wheel     3044  8 29  2015 LastResort.ttf

"LastResort.ttf" from unicode.org:

-rwxr-xr-x@ 1 root  wheel  5395052  3  3  2008 LastResort.ttf

So, there might be some confusion about these different fonts, and the one in OS X seems to have some problem. Interestingly, LastResort.ttf in OS X Lion (10.7.5)

-rw-r--r--  1 root  wheel  13894924 10  8  2011 LastResort.ttf

does not have such a problem, so no segfault occurs.

[aminophen]

I think that the segfault problem is a bug in LuaTeX engine. Tested with TL2015 frozen; that is, luaotfload 12feb16 (r39699).

When I comment out

    local info = fontloaderinfo (fullname)

in the function read_font_names, segmentation goes away. IMHO, fontloaderinfo, that is, fontloader.info (LuaTeX built-in) has something wrong.

I also confirmed that

This is LuaTeX, Version beta-0.81.1 (rev 5442)

succeeds but

This is LuaTeX, Version beta-0.85.0 (rev 5550)

fails with segfault.

[phi-gamma]

···<date: 2016-04-20, Wednesday>···<from: H. Yamashita>···

I confirmed that the segfault problem is a bug in LuaTeX engine. Tested with TL2015 frozen; that is, luaotfload 12feb16 (r39699).

Do you have a traceback or a Valgrind log?

When I comment out

    local info = fontloaderinfo (fullname)

in the function read_font_names, segmentation goes away. IMHO, that means, fontloaderinfo, that is, font loader.info (LuaTeX built-in) has something wrong.

The fontloader library won’t be used anymore with Luaotfload 2.7.

[aminophen]

I said:

that is, luaotfload 12feb16 (r39699).

So I'm talking about luaotfload v2.6 in TL2015 frozen (and also in TL2016 pretest). The call of fontloader.info by luaotfload v2.6 seems to trigger a bug of the latest LuaTeX. (I think LuaTeX should not crash at anytime, whether luaotfload use fontloader library or not.)

[aminophen]

The new version luaotfload v2.7 (from 1c93f97) works fine with LastResort.ttf from OS X El Capitan. And also, issue #328 seems to be ok with v2.7 (ttc fontnames are correct).

Maybe I should report the segfault problem to LuaTeX developers, right?

[phi-gamma]

···<date: 2016-04-20, Wednesday>···<from: H. Yamashita>···

The new version luaotfload v2.7 (from 1c93f97) works fine with LastResort.ttf from OS X El Capitan. And also, issue #328 seems to be ok with v2.7 (ttc fontnames are correct).

Maybe I should report the segfault problem to LuaTeX developers, right?

Yes, but as I wrote: Without either a free font that exhibits the
problem or a GDB backtrace / Valgrind info it’s going to be hard
to do anything about it.

However: Since the Luatex in TL 2015 is frozen and the fontloader
library does not enjoy that much maintenance any more (it’s
mostly obsolete) I don’t think it’s worth the effort.

Best,
Philipp

[aminophen]

the fontloader library does not enjoy that much maintenance any more (it’s
mostly obsolete)

Thank you for the information.

luaotfload v2.6 + LuaTeX 0.80.0 (TL2015) had no segfault problem, so there might be some mistake between 0.80.0 and 0.95.0. Anyway, if luaotfload v2.7 is uploaded to CTAN in time (before TL2016 official release), there will be no practical issue.

[phi-gamma]

···<date: 2016-04-20, Wednesday>···<from: H. Yamashita>···

the fontloader library does not enjoy that much maintenance any more (it’s
mostly obsolete)

Thank you for the information.

luaotfload v2.6 + LuaTeX 0.80.0 (TL2015) had no segfault
problem, so there might be some mistake between 0.80.0 and
0.95.0.

That is likely. 2.6 has been tested with Luatex 0.8x only, and
2.7 is targeting Luatex 0.95. As far as other combinations of
versions are concerned, the testing effort was marginal.

    Anyway, if luaotfload v2.7 is uploaded to CTAN in time

(before TL2016 official release), there will be no practical
issue.

Thank you for you vote of confidence =)

[phi-gamma]

@ALL: The new release is on its way to CTAN. Please re-test and comment on
the status.

[jfbu]

For the moment I get

$ luaotfload-tool -u -vvv
luaotfload | util : Setting the log level to 3.
luaotfload | util : Task completed successfully.
luaotfload | db : Updating the font names database.
luaotfload | db : Font names database loaded from /usr/local/texlive/2016/texmf-var/luatex-cache/generic/names/luaotfload-names.luc
luaotfload | db : Loading took 12 ms.
luaotfload | db : Blacklisted file "spltfgbd.ttf" via "/usr/local/texlive/2016/texmf-dist/tex/luatex/luaotfload/luaotfload-blacklist.cnf".
luaotfload | db : Blacklisted file "spltfgbi.ttf" via "/usr/local/texlive/2016/texmf-dist/tex/luatex/luaotfload/luaotfload-blacklist.cnf".
luaotfload | db : Blacklisted file "spltfgit.ttf" via "/usr/local/texlive/2016/texmf-dist/tex/luatex/luaotfload/luaotfload-blacklist.cnf".
luaotfload | db : Blacklisted file "spltfgrg.ttf" via "/usr/local/texlive/2016/texmf-dist/tex/luatex/luaotfload/luaotfload-blacklist.cnf".
luaotfload | db : Blacklisting 4 files and directories.
luaotfload | db : Whitelisting 0 files.
luaotfload | db : Scanning TEXMF for fonts...
luaotfload | db : Path “.” matches $PWD (“/Users/xxxx”), skipping.
luaotfload | db : Path “.” matches $PWD (“/Users/xxxx”), skipping.
luaotfload | db : Path “.” matches $PWD (“/Users/xxxx”), skipping.
luaotfload | db : Initiating scan of 515 directories.
luaotfload | db : Collected 2490 files.
luaotfload | db : Scanning system fonts...
luaotfload | db : Searching in static system directories...
luaotfload | db : Collected 340 files.
luaotfload | db : Scanning 2830 collected font files ...
luaotfload | db : Scanned 2830 files, 15 new.
luaotfload | db : Found 2830 font files; 15 new, 0 stale entries.
luaotfload | db : Creating filename map.
luaotfload | db : Analyzing families.
...texmf-dist/tex/luatex/luaotfload/luaotfload-database.lua:2733: attempt to compare number with nil

this is with

$ luaotfload-tool --version

luaotfload-tool:
        Luaotfload font management and diagnostic utility.
        License: GNU GPL v2.0.
        Report problems to <https://github.com/lualatex/luaotfload/issues>

luaotfload-tool version: "2.7"
Revision: "b1a1ee5d1ec8002acee2702e6dd070073e0ee0ee"
Lua interpreter: stock; version "Lua 5.2"
Luatex version: 0.95.0
Platform: type=unix name=macosx
    +  machine: x86_64
    + nodename: xxxxxxx.local
    +  release: 13.4.0
    +  sysname: Darwin
    +  version: Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64
Index: version="b1a1ee5d1ec8002acee2702e6dd070073e0ee0ee" created="2016-04-11 15:07:11" modified="2016-04-12 08:46:04"

Second attempt does same. Is there a more detailed log ? I pasted terminal output.

Attempt nevertheless to compile test file from issue #328 gives

luaotfload | db : Reload initiated (formats: otf,ttf,ttc,dfont); reason: "Font I
rianis ADF Style Std not found."....texmf-dist/tex/luatex/luaotfload/luaotfload-
database.lua:2733: attempt to compare number with nil.
<to be read again> 
\scan_stop: 
l.60 \setsansfont{Irianis ADF Style Std}

The lua interpreter ran into a problem, so the
remainder of this lua chunk will be ignored.


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
./testirianisluatex.tex:60: fontspec error: "font-not-found"
! 
! The font "Irianis ADF Style Std" cannot be found.
! 
! See the fontspec documentation for further information.
! 
! For immediate help type H <return>.
!...............................................  

[jfbu]

To confirm all is fine now (TL 2016 pretest, April 24, luaotfload 2.7) after applying fix about names-version = 2.7 mentioned at #337. Both for the original mwe, and the ones from #328 with Gill Sans or with Irianis ADF, and I now presume for all .ttc encapsulated fonts.

[eg9]

I'd wait before closing that the issue mentioned at #337 is solved, before closing.