Hotspot segfaulting on Linux SPARC

[David Holmes]

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 
::free

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
>>