RFR: 8334763: --enable-asan: assert(_thread->is_in_live_stack((address)this)) failed: not on stack? [v2]

[Jan Kratochvil]

On Sun, 23 Jun 2024 13:18:19 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> fastdebug:
>> 
>> 
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (/home/azul/azul/openjdk-git/src/hotspot/share/runtime/handles.inline.hpp:77), pid=878152, tid=878158
>> #  assert(_thread->is_in_live_stack((address)this)) failed: not on stack?
>> #
>> # JRE version:  (24.0) (fastdebug build )
>> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 24-internal-adhoc.azul.openjdk-git, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0x1d20658]  constantPoolHandle::constantPoolHandle(Thread*, ConstantPool*)+0x268
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement address-use-after-return

JDK is sometimes verifying `StackObj` is really on stack. And JDK does that by comparing pointer to these objects against bottom+top stack boundaries. The problem is that when ASAN does `detect_stack_use_after_return` it will allocate some autovariables (stack variables) in a separately allocated memory block, off the stack. This memory they call "fake stack". Then JDK fails its assertions `StackObj` is on stack. So we can teach JDK about "fake stack" than the pointers in "fake stack" are also in fact in the stack. That's all.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19843#issuecomment-2185906263