-
Notifications
You must be signed in to change notification settings - Fork 5.9k
8303612: runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code 139 #25689
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
… with exit code 139 replace infinite loop with conditional in do_overflow function
Hi @mz1999, welcome to this OpenJDK project and thanks for contributing! We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user mz1999" as summary for the issue. If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing |
❗ This change is not yet ready to be integrated. |
The copyright year should be updated from 2023 to 2025. |
- Change copyright year from 2023 to 2025 in the test file header
Done. Updated the copyright year to 2025 as requested. Thanks! |
/signed |
Thank you! Please allow for up to two weeks to process your OCA, although it is usually done within one to two business days. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated! |
This pull request addresses an issue in
runtime/StackGuardPages/TestStackGuardPagesNative
where the native test component (exeinvoke.c
) exhibited platform-dependent behavior and did not fully align with the intended test objectives for verifying stack guard page removal on thread detachment.Summary of the Problem:
The
test_native_overflow_initial
scenario withinTestStackGuardPagesNative
showed inconsistent results:SEGV_MAPERR
to terminate a loop that should have had a defined exit condition.The core issue was that the native code's second stack overflow attempt, designed to check for guard page removal, used an unbounded loop. Its termination (and thus the test's outcome) depended on platform-specific OS behavior regarding extensive stack allocation after guard pages are supposedly modified.
Test Objective Analysis:
The primary goal of
TestStackGuardPagesNative
, particularly for the initial thread (test_native_overflow_initial
), is to:SIGSEGV
withsi_code = SEGV_ACCERR
, indicating an active stack guard page.DetachCurrentThread()
, confirm that the previously active stack guard page is no longer enforcing the same strict protection. This is ideally demonstrated by successfully allocating stack space up to the depth that previously caused theSEGV_ACCERR
, without encountering any signal.How the Original Implementation Deviated from the Test Intent:
The native
do_overflow
function, when invoked for the second phase (to check guard page removal), implemented an unconditionalfor(;;)
loop.SEGV_ACCERR
). However, the unbounded loop meant:SEGV_MAPERR
was possible, this loop ran for an excessive duration, leading to a hang.SEGV_MAPERR
. The existing result-checking logic inrun_native_overflow
incorrectly treated thisSEGV_MAPERR
as a "pass" condition for guard page removal, which is misleading. The true indication of successful guard page removal is the absence of any signal during the controlled second allocation phase.This reliance on incidental, platform-dependent signal behavior to terminate the loop (and the misinterpretation of
SEGV_MAPERR
as a success) meant the test was not robustly verifying its core objective.Proposed Solution:
This PR modifies the
do_overflow
function inexeinvoke.c
to accurately reflect the test intent for both phases of stack overflow checking, ensuring deterministic behavior:The
do_overflow
function is updated to use a singlewhile
loop whose condition correctly handles both the initial overflow check and the subsequent verification of guard page removal:Impact and Clarity of Test Outcome with This Change:
do_overflow
. The loop now has a defined boundary based on_kp_rec_count
. This directly resolves the hang observed on platforms like CentOS 7.do_overflow
: Thedo_overflow
function will now consistently:SIGSEGV
occurs andlongjmp
is called._kp_rec_count
times. If noSIGSEGV
occurs, it will complete this bounded loop and return normally. If aSIGSEGV
does occur within these_kp_rec_count
allocations,longjmp
will be called.This refinement ensures
TestStackGuardPagesNative
more accurately and reliably verifies the stack guard page lifecycle for native threads attached to the JVM.Progress
Error
Issue
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25689/head:pull/25689
$ git checkout pull/25689
Update a local copy of the PR:
$ git checkout pull/25689
$ git pull https://git.openjdk.org/jdk.git pull/25689/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 25689
View PR using the GUI difftool:
$ git pr show -t 25689
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25689.diff