Hi, using \read on any existing file seems to trigger a segfault on lmtx. For example, take the document \starttext \newread\myread \openinputfile\myread{test} \read\myread to \abc \closeinputfile\myread \stoptext where test.tex is any file (It doesn't matter if the file is empty or not). On my system (linux x64, latest lmtx) this results in mtx-context | fatal error: return code: 139 Running the command after "executing runner 'run luametatex format':" directly gives segmentation fault (core dumped) /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex cont-yes.mkiv Tracing this command using valgrind shows ==51536== Conditional jump or move depends on uninitialised value(s) ==51536== at 0x1789A6: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x14D074: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x199599: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x15B03B: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x15838C: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x154A39: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x12090D: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x4A12001: (below main) (in /usr/lib/libc-2.31.so) ==51536== ==51536== Use of uninitialised value of size 8 ==51536== at 0x4A6003B: fclose@@GLIBC_2.2.5 (in /usr/lib/libc-2.31.so) ==51536== by 0x14D074: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x199599: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x15B03B: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x15838C: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x154A39: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x12090D: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x4A12001: (below main) (in /usr/lib/libc-2.31.so) ==51536== ==51536== Invalid read of size 4 ==51536== at 0x4A6003B: fclose@@GLIBC_2.2.5 (in /usr/lib/libc-2.31.so) ==51536== by 0x14D074: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x199599: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x15B03B: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x15838C: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x154A39: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x12090D: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x4A12001: (below main) (in /usr/lib/libc-2.31.so) ==51536== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==51536== ==51536== ==51536== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==51536== Access not within mapped region at address 0x0 ==51536== at 0x4A6003B: fclose@@GLIBC_2.2.5 (in /usr/lib/libc-2.31.so) ==51536== by 0x14D074: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x199599: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x15B03B: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x15838C: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x154A39: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x12090D: ??? (in /home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex) ==51536== by 0x4A12001: (below main) (in /usr/lib/libc-2.31.so) ==51536== If you believe this happened as a result of a stack ==51536== overflow in your program's main thread (unlikely but ==51536== possible), you can try to increase the size of the ==51536== main thread stack using the --main-stacksize= flag. ==51536== The main thread stack size used in this run was 8388608. ==51536== ==51536== HEAP SUMMARY: ==51536== in use at exit: 85,957,820 bytes in 639,104 blocks ==51536== total heap usage: 971,974 allocs, 332,870 frees, 174,449,076 bytes allocated ==51536== ==51536== LEAK SUMMARY: ==51536== definitely lost: 4,552 bytes in 236 blocks ==51536== indirectly lost: 0 bytes in 0 blocks ==51536== possibly lost: 50,271,367 bytes in 532,242 blocks ==51536== still reachable: 35,681,901 bytes in 106,626 blocks ==51536== suppressed: 0 bytes in 0 blocks ==51536== Rerun with --leak-check=full to see details of leaked memory ==51536== ==51536== Use --track-origins=yes to see where uninitialised values come from ==51536== For lists of detected and suppressed errors, rerun with: -s ==51536== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) The same documents works fine on LuaTeX (not LuaMetaTeX) based versions of ConTeXt. Best regards, Marcel
On 5/20/2020 2:39 AM, Marcel Fabian Krüger wrote:
Hi,
using \read on any existing file seems to trigger a segfault on lmtx. For example, take the document
\starttext \newread\myread \openinputfile\myread{test} \read\myread to \abc \closeinputfile\myread \stoptext
where test.tex is any file (It doesn't matter if the file is empty or not). On my system (linux x64, latest lmtx) this results in
mtx-context | fatal error: return code: 139
hm, looks like i close the file too soon (these read files are autoclosed on read) .. i'll fix it Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On Wed, May 20, 2020 at 12:13:01PM +0200, Hans Hagen wrote:
On 5/20/2020 2:39 AM, Marcel Fabian Krüger wrote:
Hi,
using \read on any existing file seems to trigger a segfault on lmtx. For example, take the document
\starttext \newread\myread \openinputfile\myread{test} \read\myread to \abc \closeinputfile\myread \stoptext
where test.tex is any file (It doesn't matter if the file is empty or not). On my system (linux x64, latest lmtx) this results in
mtx-context | fatal error: return code: 139
hm, looks like i close the file too soon (these read files are autoclosed on read) .. i'll fix it
Which file is closed here? Experiments with a custom format suggest that the read files are opened through the `open_data_file` callback, so even if they are closed they probably should be closed by calling the `.close` member of the returned table. But that never happens (This might be a related bug: In my experiments, even for files loaded with `\input`, the close function is never called.) and the issue seems to occur even if there is no real file opened for this. So I don't see why LuaMetaTeX should call fclose here at all. But anyway, thanks for looking into this. Marcel
On 5/20/2020 12:36 PM, Marcel Fabian Krüger wrote:
On Wed, May 20, 2020 at 12:13:01PM +0200, Hans Hagen wrote:
On 5/20/2020 2:39 AM, Marcel Fabian Krüger wrote:
Hi,
using \read on any existing file seems to trigger a segfault on lmtx. For example, take the document
\starttext \newread\myread \openinputfile\myread{test} \read\myread to \abc \closeinputfile\myread \stoptext
where test.tex is any file (It doesn't matter if the file is empty or not). On my system (linux x64, latest lmtx) this results in
mtx-context | fatal error: return code: 139
hm, looks like i close the file too soon (these read files are autoclosed on read) .. i'll fix it
Which file is closed here? Experiments with a custom format suggest that the read files are opened through the `open_data_file` callback, so even if they are closed they probably should be closed by calling the `.close` member of the returned table. But that never happens (This might be a related bug: In my experiments, even for files loaded with `\input`, the close function is never called.) and the issue seems to occur even if there is no real file opened for this. So I don't see why LuaMetaTeX should call fclose here at all. But anyway, thanks for looking into this. end_file_reading is always called but has to close selectively, dependent on what has been opened, eep in mind that a token list or so is also an input stream
Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
participants (2)
-
Hans Hagen -
Marcel Fabian Krüger