[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-hotspot-runtime-dev
Subject: Re: RFR(S) 8205965: SIGSEGV on write to NativeCallStack::EMPTY_STACK
From: Zhengyu Gu <zgu () redhat ! com>
Date: 2018-06-29 20:17:45
Message-ID: e7ec20fe-8822-691c-c31a-cb8d941db920 () redhat ! com
[Download RAW message or body]
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@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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic