RFR(S) 8205965: SIGSEGV on write to NativeCallStack::EMPTY_STACK

Zhengyu Gu zgu at redhat.com
Fri Jun 29 20:17:45 UTC 2018


Hi Thomas,

On 06/29/2018 03:56 PM, Thomas Stüfe wrote:
> Hi Zhengyu,
> 
> do I understand the problem right that the static initialization of
> EMPTY_STACK can be preceded by a call to MemTracker::tracking_level()?
> Otherwise I do not understand the placement new in
> MemTracker::tracking_level().
> 
Correct.

> If yes, how? Do we really run that much complex code as part of C++
> static initialization?

Because there are other static objects that call os::malloc/new in their 
constructors, and they may be initialized prior to EMPTY_STACK.

Thanks,

-Zhengyu




> 
> Thanks, Thomas
> 
> 
> On Fri, Jun 29, 2018 at 3:04 PM, Zhengyu Gu <zgu at redhat.com> wrote:
>> Hi,
>>
>> clang-6.0 and above, can deduce that NativeCallStack::EMPTY_STACK is all
>> zeros, and since it is a static constant, it places the object in the
>> read-only BSS data section.
>>
>> To workaround static initialization ordering issue, NMT has to ensure
>> EMPTY_STACK is initialized before turns itself on, which can happen in the
>> middle of initialization of other static objects. In this case, it causes
>> SIGSEGV while try to write to the read-only memory.
>>
>> The solution is to make EMPTY_STACk private and non-constant, but hands out
>> constant version.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205965
>> Webrev: http://cr.openjdk.java.net/~zgu/8205965/webrev.00/
>>
>> Test:
>>
>>    hotspot_nmt on Linux 64 (fastdebug and release)
>>
>> Thanks,
>>
>> -Zhengyu


More information about the hotspot-runtime-dev mailing list