[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#73167: [PATCH] Fix setjmp/longjmp-related crashes on Windows
From: |
Michael Käppler |
Subject: |
bug#73167: [PATCH] Fix setjmp/longjmp-related crashes on Windows |
Date: |
Tue, 10 Sep 2024 14:45:40 +0200 |
User-agent: |
Mozilla Thunderbird |
Hi all,
recently an user reported a bug to the LilyPond project, where he tried
to print
a data structure with (pretty-print), which silently failed at a certain
point inside the data structure:
https://gitlab.com/lilypond/lilypond/-/issues/6737#note_2049515997
The error did only affect LilyPond mingw builds, compiled against Guile
3.0.10, 3.0.9 was (seemingly) fine.
Bisecting showed that the error first showed up with commit
https://git.savannah.gnu.org/cgit/guile.git/commit/?id=29a9f26a36035d5425b173d101628ecc62f5a46b
which substantially reworked the pretty-print implementation to use
delimited continuations.
As it turned out, the problems only arises with the JIT turned on.
Further debugging revealed that the crash happens inside the MSVCRT
function 'RtlUnwindEx', which detects
a stack corruption and throws "STATUS_BAD_STACK". The reason is that
'setjmp' on mingw expands to
'_setjmp' that takes the current frame address as second parameter.
After a 'longjmp' call it tries to unwind
the stack up to this particular frame address. IIUC, this will fail
because the JIT'ed code does not follow
the Windows x64 calling conventions. Setting the second parameter to
NULL prevents unwinding and fixes
the issue.
Guile is not the only project using JIT compilation that faces this
Windows peculiarity.
See
https://blog.lazym.io/2020/09/21/Unicorn-Devblog-setjmp-longjmp-on-Windows/
for a nice summary.
Please consider the attached patch.
Michael
0001-Fix-setjmp-longjmp-related-crashes-on-Windows.patch
Description: Text document
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#73167: [PATCH] Fix setjmp/longjmp-related crashes on Windows,
Michael Käppler <=