On Sun, 23 Jun 2024 13:18:19 GMT, Jan Kratochvil <jkratoch...@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 It looks like __builtin_frame_address is just incompatible with ASAN. https://github.com/google/sanitizers/wiki/AddressSanitizerUseAfterReturn#compatibility https://github.com/google/sanitizers/issues/1688 So this seems like it is likely a problem with most/all uses of `os::current_stack_pointer`. With ASAN_OPTIONS=detect_stack_use_after_return=0 it sometimes compares true. With ASAN_OPTIONS=detect_stack_use_after_return=1 it sometimes compares false. And for both, instead it sometimes crashes with AddressSanitizer:DEADLYSIGNAL AddressSanitizer:DEADLYSIGNAL AddressSanitizer:DEADLYSIGNAL AddressSanitizer:DEADLYSIGNAL AddressSanitizer:DEADLYSIGNAL AddressSanitizer:DEADLYSIGNAL AddressSanitizer:DEADLYSIGNAL Segmentation fault (core dumped) I also tried the "portable" version of of `os::current_stack_pointer` referenced by that PR, and it didn't work either. Having now read https://github.com/google/sanitizers/wiki/AddressSanitizerUseAfterReturn it's obvious why that wouldn't work either. I also tried sprinkling around `__attribute__((no_sanitize("address")))`, and that didn't change anything. The "fake stack" mechanism used by the use-after-return sanitizer is just fundamentally incompatible with any kind of stack bounds checking, and possibly other things we do in HotSpot. We could apply the technique from the 2nd commit (using __asan_addr_is_in_fake_stack) to all uses of `os::current_stack_pointer`, but that's not thrilling. And that's assuming there aren't other places we're doing things with stack pointers that will be broken by the "fake stack" mechanism. I'm approaching the conclusion that the original proposal of globally disabling the use-after-return sanitizer (at least for HotSpot) might indeed be necessary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19843#issuecomment-2186065031
