OpenJDK 18 Linux Bug when Wrapping Clang, Crashes Outside Native Frames

[Joshua Suskalo]

Thanks so much for taking the time to look at this! This is immensely 
helpful!

I was able to test my larger case and it all works now. I don't know how 
I'd have found this otherwise.

I really appreciate all the work on Panama, I'm excited for the preview 
in JDK 19 and the full release beyond.

Joshua

On 2022-07-18 12:14, Maurizio Cimadamore wrote:
> Hi again,
> I've tried your Panama-only reproducer and I can confirm that the
> crash disappears if you prepend
> `LIBCLANG_DISABLE_CRASH_RECOVERY=false` to your launcher, as in:
> 
> LIBCLANG_DISABLE_CRASH_RECOVERY=false java
> -Djava.library.path=<path-to-LLVM-libs>
> --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign
> MinimalReproductionCase complex.cpp
> 
> Maurizio
> 
> On 18/07/2022 17:43, Maurizio Cimadamore wrote:
> 
>> Hi Joshua,
>> I know about coffi, and very excited to see stuff like these
>> happening - kudos!
>> 
>> As for clang, my hunch is that you are hitting the dreaded "libclang
>> crash recovery" issue - e.g.
>> 
>> https://reviews.llvm.org/D23662
>> 
>> Basically, clang installs its own signal handlers, which end up
>> overriding (at least on Linux) the signal handlers installed by the
>> JVM.
>> 
>> Our Jextract implementation (which is based on a Panama port of
>> libclang) has also to workaround this:
>> 
>> 
> https://github.com/openjdk/jextract/blob/master/src/main/java/org/openjdk/jextract/clang/LibClang.java#L54
>> 
>> 
>> (On windows, the recovery logic seems to work ok, but on Linux it
>> causes spurious crashes, pretty much all over the place).
>> 
>> In principle, setting the LIBCLANG_DISABLE_CRASH_RECOVERY variable
>> should be a quick way for you to check if that's indeed the issue.
>> 
>> Cheers
>> Maurizio