RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected crash build with clang17 [v4]
Amit Kumar
amitkumar at openjdk.org
Wed Jan 1 06:08:37 UTC 2025
On Tue, 31 Dec 2024 10:41:23 GMT, SendaoYan <syan at openjdk.org> wrote:
>> Hi all,
>> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR add `volatile` modifier to `char *t`, to make avoid clang do the "dead code" elimination. Risk is low.
>>
>> Here is the example explain the "dead code" elimination.
>>
>> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
>>
>>
>>> cat demo.c
>> int main() { char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> 0
>>
>>
>> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
>>
>>> cat demo.c
>> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>
> use guarantee(!CrashGCForDumpingJavaThread, "") to generate jvm crash
I think this will also fix the ubsan error I am getting with `runtime/ErrorHandling/TestDwarf.java` test case:
stderr: [/home/amit/ubsan/jdk/src/hotspot/share/runtime/frame.cpp:1167:8: runtime error: store to null pointer of type 'char'
#0 0x3ff8e74c3af in frame::oops_do_internal(OopClosure*, NMethodClosure*, DerivedOopClosure*, DerivedPointerIterationMode, RegisterMap const*, bool) const /home/amit/ubsan/jdk/src/hotspot/share/runtime/frame.cpp:1167
#1 0x3ff8eda2523 in frame::oops_do(OopClosure*, NMethodClosure*, RegisterMap const*) /home/amit/ubsan/jdk/src/hotspot/share/runtime/frame.hpp:483
#2 0x3ff8eda2523 in JavaThread::oops_do_frames(OopClosure*, NMethodClosure*) /home/amit/ubsan/jdk/src/hotspot/share/runtime/javaThread.cpp:1458
#3 0x3ff901f1611 in Thread::oops_do(OopClosure*, NMethodClosure*) /home/amit/ubsan/jdk/src/hotspot/share/runtime/thread.cpp:447
#4 0x3ff8edabbd1 in JavaThread::verify() /home/amit/ubsan/jdk/src/hotspot/share/runtime/javaThread.cpp:1622
#5 0x3ff90233d9f in Threads::verify() /home/amit/ubsan/jdk/src/hotspot/share/runtime/threads.cpp:1489
#6 0x3ff902bcc45 in Universe::verify(VerifyOption, char const*) /home/amit/ubsan/jdk/src/hotspot/share/memory/universe.cpp:1244
#7 0x3ff904847ad in Universe::verify(char const*) /home/amit/ubsan/jdk/src/hotspot/share/memory/universe.hpp:348
#8 0x3ff904847ad in Universe::verify() /home/amit/ubsan/jdk/src/hotspot/share/memory/universe.hpp:351
#9 0x3ff904847ad in VMThread::run() /home/amit/ubsan/jdk/src/hotspot/share/runtime/vmThread.cpp:200
#10 0x3ff901f2c99 in Thread::call_run() /home/amit/ubsan/jdk/src/hotspot/share/runtime/thread.cpp:232
#11 0x3ff8fad890f in thread_native_entry /home/amit/ubsan/jdk/src/hotspot/os/linux/os_linux.cpp:860
#12 0x3ff93496295 in start_thread nptl/pthread_create.c:442
#13 0x3ff9350ff8d (/lib/s390x-linux-gnu/libc.so.6+0x10ff8d)
Thanks @sendaoYan for looking into it.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/22757#issuecomment-2566865070
More information about the hotspot-dev
mailing list