RIP values like 0xffffffff94bf7f80 due to patched NMethod
alexandr.miloslavskiy at gmail.com
Thu Nov 15 16:41:09 UTC 2018
Vladimir, thanks for your time!
It took a couple days to receive permission from user to share his
hs_err.log files. I have submitted bugreport as you suggested (ID
9058132), but there was no way to attach those files there.
On the other hand, frankly, hs_err.log are quite useless in this
specific case. Without a core dump there was no chance to get any of the
I understand that a few bugs were fixed recently, but I guess since it
sill happens on JRE11 it's a different problem.
I also studied the code to try to find how 0x90 can get written on top
of jmp, but didn't find anything definite.
Following your lead, I have checked if crashing NMethod is freed.
* Its 'HeapBlock::Header::_used' contains 1
* NMethod fields match what they should be for old NMethod, so I think
that this block is not owned by someone else yet.
* There are no pointers to old (crashing) NMethod anywhere except
discarded (with addresses < RSP) stack of crashing thread. This worries
me a bit, but I guess I simply don't know how JVM works.
Since my last mail I debugged it a bit more and found one new fact: just
after crashing method was compiled with new optimization settings, the
calling method also was compiled, fully inlining called method and
therefore eliminating the need for called Method's NMethod. My intuition
says that should be related, because the coincidence is too obvious.
However, called Method's 'Method._code' still contains reference to new
NMethod - looks like JVM didn't realize it's not needed.
This last fact is supported by one core dump so far, I still need to
check others. Other facts I listed in my previous mail are supported by
multiple dumps (and all I have checked).
Unfortunately, the bug only reproduces for our customer.
More information about the hotspot-compiler-dev