September 2021 - dev-luatex - NTG Mailing Lists

Luatex 1.12.0 announcement.
by luigi scarso 27 May '23

27 May '23

============================================================== LuaTeX 1.12.0 2020-03-15 ============================================================== This is the release for TeX live 2020. --shell-restricted now forbids loading of dso (dll/so object) Scaled virtual font Aadditional primitives \eTeXglue[stretch|shrink]order for querying order the etex way. Extra features runtoks tex.getmodenames() (as these can differ per engine/version) Permit nested runtoks in more complex situations of nesting (HH) More accurate and correct test for tex.[set|get]math Minor clean-up and bugs fixed -- luigi

4 8

Fix for pdf_literal Lua string / token list conversions
by Michal Vlasák 06 May '23

06 May '23

Hello, take this plain LuaTeX example: \setbox0=\hbox{\pdfextension literal{0 g}} % 1) \directlua{ local literal = tex.getbox(0).head texio.write_nl("log", "literal.data="..literal.data) } \showbox0 % 2) \directlua{ local literal = tex.getbox(0).head literal.data = "test" literal.token = "toks" texio.write_nl("log", "literal.token="..(literal.token or "nil")) } \showbox0 % 3) patch test \directlua{ tex.set("everyjob", "asd") texio.write_nl("log", tex.get("everyjob")) } \bye Expected log output (abridged): 1) literal.data=0 g .\pdfliteral origin{0 g} 2) literal.token=toks .\pdfliteral origin{toks} Actual output: 1) literal.data=data .\pdfliteral origin{0 g} 2) literal.token=characters .\pdfliteral origin <lua data reference 153> In the first case the Lua accessor returns a value which happens to be on top of the stack (the key "data" itself). In the second case an index into TeX memory is misinterpreted as a Lua registry index, so the returned data is essentially garbage. Patch for both issues is attached. I also extended `tokenlist_from_lua` (which is what `nodelib_gettoks` is defined as) to allow an index argument. The previous version used the value on top of the stack, which probably worked for every use currently in LuaTeX, but seemed rather dangerous and subtle. The patch is from git, though it can be applied normally with patch -Np1 < pdf_literal.patch Kind regards, Michal Vlasák

2 3

Re: [Dev-luatex] bug#48064: texlive-* packages fail to build non-deterministically
by Ludovic Courtès 31 Dec '21

31 Dec '21

Hello, While investigating luatex crashes in the TeX Live 2020 package of GNU Guix¹, we identified the following heap corruption reported by Valgrind (this is on GNU/Linux, with glibc 2.33): --8<---------------cut here---------------start------------->8--- sh-5.0$ ~ludo/.guix-profile/bin/valgrind --extra-debuginfo-path=/gnu/store/f933bvd6ab6l2lg6xl6k1a6jwvcls0z6-glibc-2.33-debug/lib/debug "luatex" "-interaction=nonstopmode" "-output-directory=build" "&luatex" "amsbsy.dtx" ==28531== Memcheck, a memory error detector ==28531== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==28531== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==28531== Command: luatex -interaction=nonstopmode -output-directory=build &luatex amsbsy.dtx ==28531== This is LuaTeX, Version 1.12.0 (TeX Live 2020) restricted system commands enabled. ==28531== Invalid write of size 8 ==28531== at 0x485C691: lua_pushlstring (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x568E03: load_hyphenation (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x56B41C: undump_language_data (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4DFB9F: load_fmt_file (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4EF0ED: main_body (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x45118D: main (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== Address 0xae14170 is 0 bytes after a block of size 1,168 alloc'd ==28531== at 0x483EBE1: realloc (in /gnu/store/jlmh0jbgr6zn4iyvhfbvxps8pykzj5ry-valgrind-3.16.1/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==28531== by 0x46695D: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x486D932: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x48660F2: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x4868BE7: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x4868FCF: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x486988B: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x485C6BB: lua_pushlstring (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x568E03: load_hyphenation (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x56B41C: undump_language_data (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4DFB9F: load_fmt_file (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4EF0ED: main_body (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== ==28531== Invalid write of size 4 ==28531== at 0x485C6A2: lua_pushlstring (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x568E03: load_hyphenation (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x56B41C: undump_language_data (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4DFB9F: load_fmt_file (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4EF0ED: main_body (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x45118D: main (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== Address 0xae14178 is 8 bytes after a block of size 1,168 alloc'd ==28531== at 0x483EBE1: realloc (in /gnu/store/jlmh0jbgr6zn4iyvhfbvxps8pykzj5ry-valgrind-3.16.1/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==28531== by 0x46695D: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x486D932: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x48660F2: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x4868BE7: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x4868FCF: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x486988B: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x485C6BB: lua_pushlstring (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x568E03: load_hyphenation (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x56B41C: undump_language_data (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4DFB9F: load_fmt_file (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4EF0ED: main_body (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== [...] valgrind: m_mallocfree.c:305 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. valgrind: Heap block lo/hi size mismatch: lo = 1232, hi = 68. This is probably caused by your program erroneously writing past the end of a heap block and corrupting heap metadata. If you fix any invalid writes reported by Memcheck, this assertion failure will probably go away. Please try that before reporting this as a bug. --8<---------------cut here---------------end--------------->8--- Does that ring a bell? Is there a chance this problem was fixed in the meantime? Thanks in advance, Ludovic. ¹ https://issues.guix.gnu.org/48064

3 4

os.uname on 64 bit Windows
by Reinhard Kotucha 22 Dec '21

22 Dec '21

Hi, on a 64 bit Windows machine os.uname() erroneously returns machine i686 On the same machine I get under Linux machine x86_64 with both, x86_64-linux and i386-linux binaries. Thus I assume that the keyword 'machine' refers to the hardware, not to how the binaries were compiled (32 vs. 64 bit). The complete output of for k,v in pairs(os.uname()) do print(k,v) end is release build 9200 nodename R804 version 6.02 machine i686 sysname Windows 8 Regards, Reinhard -- ------------------------------------------------------------------ Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ------------------------------------------------------------------

3 8

LuaTeX doesn't discard empty paragraphs when textdir is used
by Marcel Krüger 02 Sep '21

02 Sep '21

Hi, consider the following plain LuaTeX document: \textdir TRT \noindent\par \bye without the `\textdir TRT` line or with `\textdir TLT`, this would lead to "warning (pdf backend): no pages of output.", but with the non default "\textdir", it creates an empty (except for the page number) page instead. This can be avoided by setting \pardir too: \textdir TRT\pardir TRT \noindent\par \bye again produces no output, but adding a group around it reintroduces the issue: \begingroup \textdir TRT\pardir TRT \noindent\par \endgroup \bye leads to an empty page. Of course similar things happen not only for otherwise empty documents: Instead of empty paragraphs disappearing, they add empty lines. Together, this is not only inconsistent with other engines which always discard empty paragraphs, but also leads to hard to predict behavior (especially for users who are not familiar with the implementation of LuaTeX's directional system), so I think it would be great if LuaTeX could always remove such empty paragraphs. Best, Marcel

5 9