JDK-8244744 : SIGSEGV in ImagesStrings::find() at VM shutdown (gtestlauncher)
  • Type: Bug
  • Component: tools
  • Sub-Component: jlink
  • Affected Version: 15
  • Priority: P4
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • Submitted: 2020-05-11
  • Updated: 2021-04-01
  • Resolved: 2020-11-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Relates :  
JDK-8166727 - javac crashed: [jimage.dll+0x1942] ImageStrings::find+0x28
Description
Linux x64. Reproducible on my Ubuntu box. I run the gtests by manually starting them:

./hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./images/jdk/

gtests run through, then crash after finishing.

No useful hs-err file. Getting a core was possible by cutting hs-err reporting short with:  -XX:+SuppressFatalErrorMessage -XX:+CreateCoredumpOnCrash


Backtrace:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./images/jdk/ -XX:+Sup'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f4b0ddde428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f4ad319f700 (LWP 12538))]
(gdb) bt
#0  0x00007f4b0ddde428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007f4b0dde002a in __GI_abort () at abort.c:89
#2  0x00007f4b0f22f61a in os::abort (dump_core=true, siginfo=0x0, context=0x0) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/os/linux/os_linux.cpp:1523
#3  0x00007f4b0f228703 in os::abort (dump_core=true) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/runtime/os.cpp:884
#4  0x00007f4b0f5406f7 in VMError::report_and_die (id=11, message=0x0, detail_fmt=0x7f4b0fc84341 "%s", detail_args=0x7f4ad319b8a8, thread=0x7f4abc001800, pc=
    0x7f4b0d46357d <ImageStrings::find(Endian*, char const*, int*, unsigned int)+127> "\213\nH\213U��\316H\211\327\377��E\364\203", <incomplete sequence \364>, siginfo=0x7f4ad319bcb0, context=0x7f4ad319bb80, filename=0x0, lineno=0, size=0)
    at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/utilities/vmError.cpp:1366
#5  0x00007f4b0f5403f9 in VMError::report_and_die (thread=0x7f4abc001800, sig=11, pc=0x7f4b0d46357d <ImageStrings::find(Endian*, char const*, int*, unsigned int)+127> "\213\nH\213U��\316H\211\327\377��E\364\203", <incomplete sequence \364>, siginfo=0x7f4ad319bcb0, 
    context=0x7f4ad319bb80, detail_fmt=0x7f4b0fc84341 "%s") at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/utilities/vmError.cpp:1293
#6  0x00007f4b0f54044e in VMError::report_and_die (thread=0x7f4abc001800, sig=11, pc=0x7f4b0d46357d <ImageStrings::find(Endian*, char const*, int*, unsigned int)+127> "\213\nH\213U��\316H\211\327\377��E\364\203", <incomplete sequence \364>, siginfo=0x7f4ad319bcb0, 
    context=0x7f4ad319bb80) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/utilities/vmError.cpp:1299
#7  0x00007f4b0f23d035 in JVM_handle_linux_signal (sig=11, info=0x7f4ad319bcb0, ucVoid=0x7f4ad319bb80, abort_if_unrecognized=1) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:610
#8  0x00007f4b0f236bef in signalHandler (sig=11, info=0x7f4ad319bcb0, uc=0x7f4ad319bb80) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/os/linux/os_linux.cpp:4656
#9  <signal handler called>
#10 0x00007f4b0d46357d in ImageStrings::find (endian=0x7f4b0d67e048 <NativeEndian::_native>, name=0x7f4ad319c260 "//jdk/internal/misc/TerminatingThreadLocal$1.class", redirect=0x7f4b0443001c, length=32686)
    at /shared/projects/openjdk/jdk-jdk/source/src/java.base/share/native/libjimage/imageFile.cpp:88
#11 0x00007f4b0d4649dd in ImageFileReader::find_location_index (this=0x563aa9364c20, path=0x7f4ad319c260 "//jdk/internal/misc/TerminatingThreadLocal$1.class", size=0x7f4ad319d2a0)
    at /shared/projects/openjdk/jdk-jdk/source/src/java.base/share/native/libjimage/imageFile.cpp:467
#12 0x00007f4b0d465d61 in JIMAGE_FindResource (image=0x563aa9364c20, module_name=0x7f4b0f80a681 "", version=0x7f4b1055e6a0 <get_jimage_version_string()::version_string> "15.0", name=0x7f4ab4055380 "jdk/internal/misc/TerminatingThreadLocal$1.class", size=0x7f4ad319d2a0)
    at /shared/projects/openjdk/jdk-jdk/source/src/java.base/share/native/libjimage/jimage.cpp:139
#13 0x00007f4b0ea2289d in ClassPathImageEntry::open_stream_for_loader (this=0x563aa9364d20, name=0x7f4ab4055380 "jdk/internal/misc/TerminatingThreadLocal$1.class", loader_data=0x563aa94966a0, __the_thread__=0x7f4abc001800)
    at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/classfile/classLoader.cpp:390
#14 0x00007f4b0ea22830 in ClassPathImageEntry::open_stream (this=0x563aa9364d20, name=0x7f4ab4055380 "jdk/internal/misc/TerminatingThreadLocal$1.class", __the_thread__=0x7f4abc001800) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/classfile/classLoader.cpp:378
#15 0x00007f4b0ea25a5e in ClassLoader::load_class (name=0x563aa97bbda0, search_append_only=false, __the_thread__=0x7f4abc001800) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/classfile/classLoader.cpp:1237
#16 0x00007f4b0f472057 in SystemDictionary::load_instance_class (class_name=0x563aa97bbda0, class_loader=..., __the_thread__=0x7f4abc001800) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/classfile/systemDictionary.cpp:1550
#17 0x00007f4b0f46fd92 in SystemDictionary::resolve_instance_class_or_null (name=0x563aa97bbda0, class_loader=..., protection_domain=..., __the_thread__=0x7f4abc001800) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/classfile/systemDictionary.cpp:882
#18 0x00007f4b0f46e406 in SystemDictionary::resolve_instance_class_or_null_helper (class_name=0x563aa97bbda0, class_loader=..., protection_domain=..., __the_thread__=0x7f4abc001800)
    at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/classfile/systemDictionary.cpp:302
#19 0x00007f4b0f46e2d4 in SystemDictionary::resolve_or_null (class_name=0x563aa97bbda0, class_loader=..., protection_domain=..., __the_thread__=0x7f4abc001800) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/classfile/systemDictionary.cpp:285
#20 0x00007f4b0f46dfdf in SystemDictionary::resolve_or_fail (class_name=0x563aa97bbda0, class_loader=..., protection_domain=..., throw_error=true, __the_thread__=0x7f4abc001800) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/classfile/systemDictionary.cpp:233
#21 0x00007f4b0eaa8b9f in ConstantPool::klass_at_impl (this_cp=..., which=59, save_resolution_error=true, __the_thread__=0x7f4abc001800) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/oops/constantPool.cpp:512
#22 0x00007f4b0e949be6 in ConstantPool::klass_at (this=0x7f4ae85ed060, which=59, __the_thread__=0x7f4abc001800) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/oops/constantPool.hpp:421
#23 0x00007f4b0ed5efba in InterpreterRuntime::_new (thread=0x7f4abc001800, pool=0x7f4ae85ed060, index=59) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/interpreter/interpreterRuntime.cpp:230
#24 0x00007f4af5459c6d in ?? ()
#25 0x00007f4af5459be1 in ?? ()
#26 0x00007f4ad319dc18 in ?? ()
#27 0x00007f4ae85eda78 in ?? ()
#28 0x00007f4ad319dc68 in ?? ()
#29 0x00007f4ae8752288 in ?? ()
#30 0x0000000000000000 in ?? ()
(gdb) 

VM was built from current Jdk head. My tip:

thomas@mainframe:/shared/projects/openjdk/jdk-jdk/source/src$ hg tip
changeset:   59233:a662625813af
tag:         tip
user:        chagedorn
date:        Mon May 11 12:57:39 2020 +0200
summary:     8244207: Simplify usage of Compile::print_method() when debugging with gdb and enable its use with rr
Comments
Likely same issue of closing jimage before threads have completed.
01-04-2021
Tanks, David, for the confirmation.
11-03-2021
The gtests don't terminate the JVM process in a safe way. Depending on what you are experimenting with you may see all kinds of interesting issues - see discussion in JDK-8261916, where we also see this kind of crash frequently. It seems likely the image has been unmapped. Update: yes [~iklam ] spotted this. The ImageFileReaderTable is a static and so its destructor will be called at process exit time, and that will close/delete the image file. Normal VM termination mechanism take the VM to a safepoint so no further use of the image can be in progress, but the gtests, and potentially other native applications using the VM could call exit() directly and so encounter this problem.
11-03-2021
No reoccurrence. Lets close this for now.
13-11-2020
This continues to be very elusive. I see this once every n weeks or so, and trying to reproduce usually fails.
30-07-2020
It's most likely memory corruption caused by some other activity. After all, millions of programs thrash the jimage code constantly. // Match up a string in a perfect hash table. // Returns the index where the name should be. // Result still needs validation for precise match (false positive.) s4 ImageStrings::find(Endian* endian, const char* name, s4* redirect, u4 length) { // If the table is empty, then short cut. if (!redirect || !length) { return NOT_FOUND; } // Compute the basic perfect hash for name. s4 hash_code = ImageStrings::hash_code(name); // Modulo table size. s4 index = hash_code % length; // Get redirect entry. // value == 0 then not found // value < 0 then -1 - value is true index // value > 0 then value is seed for recomputing hash. s4 value = endian->get(redirect[index]); <<<<<<<<<<<<<<<<<< HERE // if recompute is required. if (value > 0 ) { // Entry collision value, need to recompute hash. hash_code = ImageStrings::hash_code(name, value); // Modulo table size. return hash_code % length; } else if (value < 0) { // Compute direct index. return -1 - value; } // No entry found. return NOT_FOUND; } Possible causes: 1. If the redirect field (should also be constant for the full run) has been overwritten and referencing the nether world. 2. The index is clipped to the length of the array (hash_code % length), so if the length field (which will be constant for the full run) has been overwritten and access thru redirect is in the nether world. 3. If the memory mapped page that redirect references has been unmapped (image closed.) Unlikely, but... If this is reproducible then I'd say one of the tests has it in for the jimage. Isolate the test and set up a simple testbed that someone can analyze further.
13-05-2020
Thanks David. This is weird. I got all kind of strange crashes yesterday - which is very uncommon for the OpenJDK, it is usually quite stable. I did clean rebuilds left and right but it kept crashing in random places. But now it seems gone. I'll close the issue.
12-05-2020
I was unable to reproduce this on my OL 7.6 x64 box with tip: changeset: 59246:bbdcc6741915 tag: tip user: yzhang date: Tue May 12 10:19:01 2020 +0800 summary: 8242429: Better implementation for sign extract
12-05-2020
Reoccurred today in my current fastdebug build.
12-05-2020