Hotspot segfaulting on Linux SPARC

[Zhengyu Gu]

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?

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