Font fallback crashes LuaLaTeX: attempt to index a nil value (local 'f') in luaotfload-fallback.lua

[cderv]

Using a font fallback list and then typesetting with that font crashes LuaLaTeX. Minimal example, using only Latin Modern (ships with TeX Live) and fontspec:

\documentclass{article}
\usepackage{fontspec}
\directlua{luaotfload.add_fallback("myfallback", {"Latin Modern Roman"})}
\setmonofont[RawFeature={fallback=myfallback}]{Latin Modern Mono}
\begin{document}
\texttt{hello}
\end{document}

lualatex aborts:

luaotfload | db : Reload initiated (formats: otf,ttf,ttc); reason: Font "Latin Modern Roman;-fallback" not found.
luaotfload | resolve : sequence of 3 lookups yielded nothing appropriate.
...luaotfload-fallback.lua:50: attempt to index a nil value (local 'f').

The crash looks like it is in the fallback table builder, where the fallback entry gets ;-fallback appended and is passed to define_font:

luaotfload/src/luaotfload-fallback.lua

Lines 40 to 50 in f0d45e3

	local f = define_font(names[i] .. ';-fallback', size)
	local fid
	if type(f) == 'table' then
	fid = font.define(f)
	definers.register(f, fid)
	elseif f then
	fid = f
	f = font.getfont(fid)
	end
	lookup[-i] = f -- Needed for multiscript interactions
	for uni, _ in next, f.characters do

Reading this, define_font(names[i] .. ';-fallback', size) appears to return nil, so f is nil at line 50 and f.characters raises the error — please correct me if I'm misreading.

The nil seems to come from define_font itself. Probing it directly:

\directlua{
  local df = luaotfload.define_font
  texio.write_nl('plain:    ' .. type(df('Latin Modern Roman', 10*65536)))
  texio.write_nl('suffixed: ' .. type(df('Latin Modern Roman;-fallback', 10*65536)))
}

plain:    number
suffixed: nil

define_font('Latin Modern Roman', size) resolves to a font id, but the same name with the ;-fallback suffix returns nil. From the log it looks like the resolver treats the whole string as a font name (reason: Font "Latin Modern Roman;-fallback" not found) rather than handling -fallback as a feature, but I may be wrong about why it doesn't resolve. Two layers seem involved — define_font returning nil for the ;-fallback request, and line 50 dereferencing f without guarding against that nil — but I'll leave the right fix to you.

I can reproduce reliably with the examples above. The lines linked above are unchanged on current main (HEAD f0d45e3).

For context, this surfaced through pandoc's font fallback options (mainfontfallback / monofontfallback), which generate the luaotfload.add_fallback(...) + RawFeature={fallback=...} LaTeX shown above. Any document using a font fallback hits it, since the fallback table is built on first use of the font.

Reproducing straight from pandoc

---
monofont: Latin Modern Mono
monofontfallback:
  - Latin Modern Roman
---
Inline `code`.

pandoc doc.md -t latex -s -o doc.tex
lualatex doc.tex

doc.tex fails with the same luaotfload-fallback.lua:50 error.

Versions: luaotfload v3.29 (2024-12-03), fontloader 2023-12-28, LuaHBTeX 1.24.0, pandoc 3.9.0.2, TeX Live 2026.

[Udi-Fogiel]

it works with

\documentclass{article}
\usepackage{fontspec}
\directlua{luaotfload.add_fallback("myfallback", {"Latin Modern Roman:"})}
\setmonofont[RawFeature={fallback=myfallback}]{Latin Modern Mono}
\begin{document}
\texttt{hello}
\end{document}

[cderv]

Thanks @Udi-Fogiel, that works on my end.

From what I can tell, the crash comes from the ;-fallback feature appended to
each fallback name: without a trailing : the name parser seems to absorb it
(Latin Modern Roman;-fallback), the lookup fails, and the resulting nil is
then indexed in luaotfload-fallback.lua. The : ends the name so ;-fallback
parses as a feature instead. Does that match your understanding?

One thing that might be worth considering (entirely your call): erroring with the
offending font name when the lookup returns nil, so an unresolvable fallback
gives a clearer message than attempt to index a nil value.

For context, I ran into this through Quarto, whose PDF template (derived from
pandoc's) emits colon-less fallback names. I'll fix it on the Quarto side and send
a pandoc patch — just flagging in case other tools hit the same thing.

[Udi-Fogiel]

Does that match your understanding?

Yes, that is what's happening here I believe.

One thing that might be worth considering (entirely your call):

well not my call :) (unless not directed to me).

For context, I ran into this through Quarto, whose PDF template (derived from pandoc's) emits colon-less fallback names. I'll fix it on the Quarto side and send a pandoc patch — just flagging in case other tools hit the same thing.

Maybe my last comment was a bit too short. Fallback fonts do not inherit the features from their base font. The only thing that is inherited is the size. This bug should probably be fixed, but practically Quarto/pandoc or anyone who use fallback fonts should/would probably set some features, mode, script, language etc. But maybe I'm wrong here, and I'm not sure what is you use case.

[Udi-Fogiel]

Also note that with

\documentclass{article}
\usepackage{fontspec}
\directlua{luaotfload.add_fallback("myfallback", {"Latin Modern Roman"})}
\setmonofont[RawFeature={fallback=myfallback}]{Latin Modern Mono}
\begin{document}
\texttt{hello}
\end{document}

the fallback does not respect bold, italics etc., all will fallback to the regular shape (or the shape you specified in the fallback).
For example

\documentclass{article}
\usepackage{fontspec}
\directlua{luaotfload.add_fallback("myfallback", {"David CLM:"})}
\setmainfont[RawFeature={fallback=myfallback,color=FF0000}]{Latin Modern Mono}
\begin{document}
Test נסיון \textit{Test נסיון}
\end{document}

[cderv]

Thanks a lot for the additional details. I am not a strong expert on LaTex, I'll look into this and see what is best for our tools. It seems I need to really understand how this fontback font works with lualatex. Thank you

[cderv]

I understand mode is expected or at least a :

One need to know but I'll help user on quarto side with that.

Thanks for taking the time to explain.