Hotspot segfaulting on Linux SPARC

[David Holmes]

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=<optimized 
out>) 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=<optimized out>) 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 report_vm_error (file=0xffff800101f3fd58 
>>>>> detail_fmt=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 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=<optimized out>) at 
>>>>> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:59 
>>>>>
>>>>> #26 VM_Version::platform_features () at 
>>>>> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:184 
>>>>>
>>>>> #27 0xffff800101eea080 in VM_Version::determine_features () at
>>>>> #28 0xffff800101da1ed0 in Threads::create_vm 
>>>>> (args=args at entry=0xffff800102638d78, 
>>>>> canTryAgain=canTryAgain at entry=0xffff800102638c57) at 
>>>>> /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3637
>>>>> #29 0xffff800101570a78 in JNI_CreateJavaVM_inner 
>>>>> (args=0xffff800102638d78, penv=0xffff800102638d70, 
>>>>> vm=0xffff800102638d68) at 
>>>>> /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:3929
>>>>> #30 JNI_CreateJavaVM (vm=0xffff800102638d68, 
>>>>> penv=0xffff800102638d70, args=0xffff800102638d78) at 
>>>>> /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:4024
>>>>> #31 0xffff8001003bfa74 in InitializeJVM (ifn=<synthetic pointer>, 
>>>>> penv=0xffff800102638d70, pvm=0xffff800102638d68) at 
>>>>> /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:1478
>>>>> #32 JavaMain (_args=<optimized out>) at 
>>>>> /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:411
>>>>> #33 0xffff8001002a3874 in start_thread (arg=0xffff800102639910) at 
>>>>> pthread_create.c:463
>>>>> #34 0xffff8001006bf140 in __thread_start () 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::verify_memory:
>>>>
>>>> static void verify_memory(void* ptr) { // <--- frame #23
>>>>    GuardedMemory guarded(ptr);
>>>>    if (!guarded.verify_guards()) {
>>>>      LogTarget(Warning, malloc, free) lt;
>>>>      ResourceMark rm; // <--- frame #22
>>>>      LogStream ls(lt);
>>>>      ls.print_cr("## nof_mallocs = " UINT64_FORMAT ", nof_frees = " 
>>>> UINT64_FORMAT...
>>>>      ls.print_cr("## memory stomp:");
>>>>      guarded.print_on(&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
>>>>