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().

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