P1
I recently had a couple of hotspot_tier1 jtreg tests start reliably failing on my development machine (linux_64, Ubuntu 14.04, jdk builds using the Oracle devkit (gcc4.9)). The failing tests are:
runtime/jni/CalleeSavedRegisters/FPRegs.java
runtime/StackGuardPages/testme.sh
The problem in both cases is a SIGSEGV that seems to arise from a stack overflow. In both tests the ThreadStackSize is 1M (which is the default for this platform. (The StackGuardPages test uses explicit -Xss1M, the CalleeSavedRegisters test defaults.) Increasing the ThreadStackSize value to 2M allows both tests to pass.
These tests don't fail for everyone, though I've had confirmation of failure from another developer, so the problem is not unique to my environment. These tests were passing for me until recently. I went back to a local repo that I hadn't touched since late April, and reproduced the failures there now, even though they didn't fail when I set it aside to work on other things. So it looks like some change in my build/test environment is producing these failures.
I've also reproduced the failures with a fresh clone of jdk9/dev.
There was a recent linux kernel / glibc change involving stack guards to address CVE-2017-1000364. I installed the Ubuntu upgrade with that change a few days ago, which roughly corresponds to when these failures appeared for me. Not yet a smoking gun (I need to try downgrading and see if the test failures go away), but a hypothesis to explore. If that's the cause, it would seem to indicate that fix can cause Java applications that used to run fine to now crash.
runtime/jni/CalleeSavedRegisters/FPRegs.java
runtime/StackGuardPages/testme.sh
The problem in both cases is a SIGSEGV that seems to arise from a stack overflow. In both tests the ThreadStackSize is 1M (which is the default for this platform. (The StackGuardPages test uses explicit -Xss1M, the CalleeSavedRegisters test defaults.) Increasing the ThreadStackSize value to 2M allows both tests to pass.
These tests don't fail for everyone, though I've had confirmation of failure from another developer, so the problem is not unique to my environment. These tests were passing for me until recently. I went back to a local repo that I hadn't touched since late April, and reproduced the failures there now, even though they didn't fail when I set it aside to work on other things. So it looks like some change in my build/test environment is producing these failures.
I've also reproduced the failures with a fresh clone of jdk9/dev.
There was a recent linux kernel / glibc change involving stack guards to address CVE-2017-1000364. I installed the Ubuntu upgrade with that change a few days ago, which roughly corresponds to when these failures appeared for me. Not yet a smoking gun (I need to try downgrading and see if the test failures go away), but a hypothesis to explore. If that's the cause, it would seem to indicate that fix can cause Java applications that used to run fine to now crash.
There are no Sub-Tasks for this issue.