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