Hotspot segfaulting on Linux SPARC (original) (raw)

David Holmes david.holmes at oracle.com
Mon Apr 9 12:33:01 UTC 2018

On 9/04/2018 10:03 PM, Zhengyu Gu wrote:

Hi David,

On 04/08/2018 05:39 PM, David Holmes wrote: On 6/04/2018 11:16 PM, Zhengyu Gu wrote:

I think it is symptom, the real cause is:

In CPUinfo constructor: string = strdup(vstr); should be: string = os::strdup(vstr, mtInternal); There's definitely a mismatch there. But I think there is also a real problem that we may end up in code that requires an attached thread and we don't have one yet. I'd be more inclined to change the os::free to a ::freeHi Why we need an attached thread here?

From the crash report:

#19 0xffff800101e74cc0 in VMError::report_and_die (thread=0x0, context=context at entry=0x0, filename=filename at entry=0xffff800101f3fd58 "/srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp", lineno=lineno at entry=720, message=message at entry=0xffff800101f3fd30 "assert(current != __null) failed", detail_fmt=detail_fmt at entry=0xffff800101f3fd00 "Thread::current() called on detached thread", detail_args=) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1244 #20 0xffff8001010e5d74 in report_vm_error (file=0xffff800101f3fd58 "/srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp", line=line at entry=720, error_msg=0xffff800101f3fd30 "assert(current != __null) failed", detail_fmt=0xffff800101f3fd00 "Thread::current() called on detached thread") at /srv/openjdk/hs/src/hotspot/share/utilities/debug.cpp:230 #21 0xffff800101a48fc0 in Thread::current () at /srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp:720 #22 ResourceMark::ResourceMark (this=0xffff800102638600) at /srv/openjdk/hs/src/hotspot/share/memory/resourceArea.hpp:109 #23 verify_memory (ptr=ptr at entry=0xffff80010400fda0) at /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:632 #24 0xffff800101a4ea74 in os::free (memblock=0xffff80010400fda0) at /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:783 #25 0xffff800101ee9df0 in CPUinfo::~CPUinfo (this=0xffff800102638888, __in_chrg=) at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:59

The use of the os* functions can lead us into code that uses ResourceMark and requires an attached thread.

David

Thanks, -Zhengyu

David -Zhengyu

On 04/06/2018 09:12 AM, Aleksey Shipilev wrote: I would say dig here: On 04/06/2018 03:02 PM, John Paul Adrian Glaubitz wrote: #20 0xffff8001010e5d74 in reportvmerror (file=0xffff800101f3fd58 detailfmt=0xffff800101f3fd00 "Thread::current() called on detached thread") at #21 0xffff800101a48fc0 in Thread::current () at /srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp:720 #22 ResourceMark::ResourceMark (this=0xffff800102638600) at /srv/openjdk/hs/src/hotspot/share/memory/resourceArea.hpp:109 #23 verifymemory (ptr=ptr at entry=0xffff80010400fda0) at /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:632 #24 0xffff800101a4ea74 in os::free (memblock=0xffff80010400fda0) at /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:783 #25 0xffff800101ee9df0 in CPUinfo::~CPUinfo _(this=0xffff800102638888, inchrg=) at /srv/openjdk/hs/src/hotspot/oscpu/linuxsparc/vmversionlinuxsparc.cpp:59

#26 VMVersion::platformfeatures () at /srv/openjdk/hs/src/hotspot/oscpu/linuxsparc/vmversionlinuxsparc.cpp:184 #27 0xffff800101eea080 in VMVersion::determinefeatures () at #28 0xffff800101da1ed0 in Threads::createvm (args=args at entry=0xffff800102638d78, canTryAgain=canTryAgain at entry=0xffff800102638c57) at /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3637 #29 0xffff800101570a78 in JNICreateJavaVMinner (args=0xffff800102638d78, penv=0xffff800102638d70, vm=0xffff800102638d68) at /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:3929 #30 JNICreateJavaVM (vm=0xffff800102638d68, penv=0xffff800102638d70, args=0xffff800102638d78) at /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:4024 #31 0xffff8001003bfa74 in InitializeJVM (ifn=, penv=0xffff800102638d70, pvm=0xffff800102638d68) at /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:1478 #32 JavaMain (args=) at /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:411 #33 0xffff8001002a3874 in startthread (arg=0xffff800102639910) at pthreadcreate.c:463 _#34 0xffff8001006bf140 in threadstart () at ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78 Backtrace stopped: previous frame identical to this frame (corrupt stack?) I think this means we are trying to use Resource area before the thread is fully initialized. IIRC that is forbidden. Looking at os::verifymemory: static void verifymemory(void* ptr) { // <--- frame #23 GuardedMemory guarded(ptr); if (!guarded.verifyguards()) { LogTarget(Warning, malloc, free) lt; ResourceMark rm; // <--- frame #22 LogStream ls(lt); ls.printcr("## nofmallocs = " UINT64FORMAT ", noffrees = " UINT64FORMAT... ls.printcr("## memory stomp:"); guarded.printon(&ls); fatal("memory stomping error"); } } It seems we have failed the guarded memory check, entered the branch, and then failed reporting the failure. This must mean buffer overrun somewhere? Thanks, -Aleksey

More information about the hotspot-dev mailing list