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

[Zhengyu Gu]

Hi Martin,


On 07/02/2018 03:26 PM, Martin Buchholz wrote:
> Zhengyu,
> 
> Thanks for fixing this!
> 
> I would have tried to use /Construct On First Use Idiom/
> https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use
> but nothing here is easy, unlike in Java with its static finals.
> (and I'm not (yet) a hotspot engineer)

Thanks for the link.

However, this pattern does not apply here, since we *cannot* allocate 
any objects at this point.

Hotspot disables global new operator, and allocates any CHeapObj here 
will loop back to initialize NMT (when it is on). We have to workaround 
this problem in several places, see comments in 
services/mallocSiteTable.hpp, for an example.

Thanks,

-Zhengyu

> 
> 
> On Fri, Jun 29, 2018 at 6:04 AM, Zhengyu Gu <zgu at redhat.com 
> <mailto: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
>     <https://bugs.openjdk.java.net/browse/JDK-8205965>
>     Webrev: http://cr.openjdk.java.net/~zgu/8205965/webrev.00/
>     <http://cr.openjdk.java.net/~zgu/8205965/webrev.00/>
> 
>     Test:
> 
>        hotspot_nmt on Linux 64 (fastdebug and release)
> 
>     Thanks,
> 
>     -Zhengyu
> 
>