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