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

Thomas Stüfe thomas.stuefe at gmail.com
Fri Jun 29 19:56:13 UTC 2018


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?

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