Why no hs-err file on CheckJNI?

[David Holmes]

Hi Thomas,

On 24/08/2021 12:27 am, Thomas Stüfe wrote:
> Hi,
> 
> when we specify CheckJNI or CheckJNICalls and we catch an error (e.g. a
> memory overwriter), we write a short report, then abort. See:
> 
> https://github.com/openjdk/jdk/blob/594e5161b48382d61509b4969bc8f52c3c076452/src/hotspot/share/prims/jniCheck.hpp#L36-L41
> 
> This has been introduced in 2008 with JDK-6739363 "Xcheck jni doesn't check
> native function arguments". I could find no discussion about this on
> mailing list archives.

There have been a number of updates to Xcheck:jni since then and in 17 I 
documented the different kinds of checks and their behaviour in more 
detail (JDK-8260194):

https://htmlpreview.github.io/?https://github.com/openjdk/jdk17/blob/4f336dd3985b654dc3fbacabdcfccf590ea918e5/java.html

> Does anyone know why we don't write a normal hs-err file in this case?

Because the intent is to mimic throwing an exception and exiting and it 
is not a "hotspot error" it is an application error.

> Would anyone care if we did? We do so in similar cases, e.g. if os::free()
> catches an overwrite.

os::free() is capturing an internal hotspot programming error, not an 
error in user code.

You would need to rework the header error messages etc and remove the 
bug reporting stuff so that the user doesn't think it is an error in the 
VM itself. Overall I don't see the need to do it as the main thing is 
the stacktrace to see where the bad JNI usage occurred - and as I said 
this isn't a VM error.

It might also introduce compatibility issues for anyone who runs testing 
wiith -Xcheck:jni and doesn't expect to get the hs_err file - though if 
you keep the current output but also produce a modified hs_err file that 
may be okay. But I still question why you would need this?

Cheers,
David

> Thanks, Thomas
>