JVM crashes in JIT compiled code without hs_err_pid file

[Thomas Stüfe]

Hi Alexandr,

(ccing hotspot-compiler-dev since this is about code cache registration on
Windows x64).

at this point, I'm taking wild guesses. Of course, this is not stock
OpenJDK but Zulu 17 so Azul support should look into this.

Possibility 1: someone in the process may have established a competing
signal handler via AddVectoredExceptionHandler. Could be some foreign
native code. On Windows x64 and x86, we use Structured Exception Handling,
but VEH has preference. If someone were to establish their own exception
handler, that one would get called, and our signal handler would be
skipped. This is just theoretical, I have not tried it. On *nix, we have
safeguarding mechanism to catch such errors (Xcheck:jni), but I'm not sure
they work on Windows.

Possibility 2: registering code cache did not work, or there is some bug.
Since the code cache is address-stable after VM init this is improbable.
Note that this is also true for +UseSegmentedCodeCache - still just one
fixed address range.

This is getting into guessing territory and there is not much more I can
contribute from outside, sorry.

Cheers, Thomas


On Sun, Feb 19, 2023 at 12:06 PM Alexandr Miloslavskiy <
alexandr.miloslavskiy at syntevo.com> wrote:

> Hi Thomas,
>
> Thank you for your reply!
>
> > Do you crash right away, or do other
> > signals from code heap generally work (e.g. polling page faults)?
>
> According to the dump and customer's description, it crashes
> intermittently. In the dump I seen, the process uptime was over 30
> minutes, so it must have handled a lot of exceptions already and then,
> all of sudden, it crashes. According to event log user sent, he had 6
> crashes in 14 hours.
>
> One other thing to consider, user says that crashes started a few days
> ago. No idea what that means currently. I suspected 3rd party software,
> but I simply can't explain what could it be doing to trigger such symptoms.
>
> > Do the UNWIND information look correct?
>
> Unfortunately not seen in the dump. I requested a full dump, but that
> may run into confidentiality issues. Waiting for customer's response
> currently.
>
> > Have you confirmed that the addresses of the faulting instructionreally
> lie within a registered UNWIND region?
>
> Yes, as can be seen in my previous mail, registered region is
> MinimumAddress=00000000`05CD0000 MaximumAddress=00000000`14CD0000
>
> and faulting RIP is
> 00000000`0e11f32b
>
> So it's in between, and it also confirms that this is Java's code cache.
>
> > Another possibility, albeit unlikely, is that in your build the outer
> > __try/__except maybe does not work, or is missing?
>
> That's stock Azul Zulu. I wouldn't expect such serious changes in JDK.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-compiler-dev/attachments/20230219/f596c77d/attachment.htm>