RFR: 8303612: runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code 139

[mazhen]

On Tue, 5 Aug 2025 02:28:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi @jdksjolen ,
>> 
>> Following up on this. As per the bot's message two weeks ago, I've been waiting for my OCA to be processed, but it seems to be stuck.
>> I understand that PRs are not reviewed until the OCA is cleared, but since the suggested two-week waiting period has passed, I was hoping someone could help to check or escalate the status of my OCA application internally.
>> 
>> My Oracle Account Email: mz1999 at gmail.com
>> 
>> Any help would be greatly appreciated. Thank you!
>
> @mz1999 the forever-loop was added as part of the "hardening" changes by JDK-8295344, so it seems you are saying that introduced a new bug? How does your proposed change compare to the code that we had prior to the "hardening"? I just want to try and see what the original problem with this code was. Thanks

Hi @dholmes-ora and @jdksjolen ,

Thank you so much for your insightful comments and for pointing me to the relevant JBS issues. After studying the history you pointed me to in JDK-8295344 and JDK-8293452, I think I have a better understanding of the evolution of this test and the critical reasoning behind the "hardening" fix.

Here’s my understanding of the test's journey, which I hope clarifies my intention with this PR.

### The Original Recursive Implementation

The original implementation was recursive, which looked something like this:


// Generation 1: Recursive and Bounded
void do_overflow(){
  int *p = alloca(sizeof(int));
  if (_kp_rec_count == 0 || _rec_count < _kp_rec_count) {
      _rec_count ++;
      do_overflow();
  }
}


My reading of `JDK-8293452` shows that the original test had a critical flaw: its **recursive nature** could corrupt the stack, leading to an unpredictable crash later in `DetachCurrentThread()`.

### The "Hardening" Fix (Iterative but Unbounded)

The "hardening" fix in `JDK-8295344` was created specifically to solve this by replacing recursion with an iterative `for(;;)` loop.


// Generation 2: Iterative but Unbounded
void do_overflow(){
  volatile int *p = NULL;
  if (_kp_rec_count == 0 || _rec_count < _kp_rec_count) {
    for(;;) {
      _rec_count++;
      p = (int*)alloca(128);
      _peek_value = p[0]; // Peek
    }
  }
}

While this successfully eliminated the stack corruption from `JDK-8293452`, it inadvertently introduced the new platform-dependent hang.

### My Proposed Change (Iterative and Bounded)

My proposed change is an evolution of this iterative approach, not a regression to recursion. It retains the iterative nature of the hardening fix but adds a boundary condition to the loop:


// Generation 3 (My PR): Iterative and Bounded
void do_overflow(){
  volatile int *p = NULL;
  while (_kp_rec_count == 0 || _rec_count < _kp_rec_count) {
    _rec_count++;
    p = (int*)alloca(128);
    _peek_value = p[0]; // Peek
  }
}


It retains the crucial **iterative** approach from `JDK-8295344` (solving the stack corruption from `JDK-8293452`), while also adding the necessary **boundary** (solving the hang introduced by `JDK-8295344`).

I believe this approach resolves both the original crash and the subsequent hang.

Thank you again for your guidance and patience.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-3232329368