Backporting stack guard fixes from JDK-9 (8169373+8159335+8139864)

[Thomas Stüfe]

On Wed, Dec 13, 2023 at 5:03 PM Jan Kratochvil (Azul) <jkratochvil at azul.com>
wrote:

> Hi Thomas,
>
> On Thu, 07 Dec 2023 00:22:34 +0800, Thomas Stüfe wrote:
> > are you sure this crash is related to JDK-8169373?
>
> No.
>
>
> > As far as I remember that bug resulted in threads possibly failing to
> start
> > because the thread stack size specified was too small;
> > I don't see how it can cause crashes like the one you describe. Once the
> > thread had been started successfully, things should work, no?
>
> The thread crashes still very early - in its glibc startup. As its TLS
> address
> (which is in the top last page of its stack) is unmapped. I expect another
> thread could accidentally unmap the pages due to some discrepancy of stack
> boundaries calculations between glibc and JVM. JVM was fixing some that
> stuff
> in:
>         JDK-8169373: Work around linux NPTL stack guard error
>
> hotspot/src/os/linux/vm/os_linux.cpp:
> bool os::pd_create_stack_guard_pages(char* addr, size_t size) {
>   if (os::is_primordial_thread()) {
> ...
>     if (stack_extent < (uintptr_t)addr) {
>       ::munmap((void*)stack_extent, (uintptr_t)(addr - stack_extent));
>
>
>
This coding only gets executed for the primordial thread, and the only way
that could happen is if the hotspot had been embedded into a custom
launcher. Is this the case here?

The normal java launcher invokes the JVM on a newly spawned pthread, so
is_primordial_thread will always be false.

..Thomas

Thanks for hints,
> Jan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20231215/cfd1c28b/attachment-0001.htm>