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

mz1999 · 2025-06-09T06:53:20Z

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 within TestStackGuardPagesNative showed inconsistent results:

On certain Linux distributions (e.g., CentOS 7), the test would hang and eventually time out during its second phase of stack allocation.
On other distributions (e.g., Ubuntu 24), the test would pass, but this pass was found to be coincidental, relying on an unintended 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:

Verify Guard Page Presence: Confirm that when a native thread is attached to the JVM, a deliberate stack overflow triggers a SIGSEGV with si_code = SEGV_ACCERR, indicating an active stack guard page.
Verify Guard Page Removal/Modification: After the thread detaches from the JVM via 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 the SEGV_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 unconditional for(;;) loop.

Intended Logic vs. Actual Behavior: The test intended for this second phase to demonstrate that allocations up to the prior failure depth are now "clean" (no SEGV_ACCERR). However, the unbounded loop meant:
- On systems like CentOS 7, where deep stack allocation without an immediate SEGV_MAPERR was possible, this loop ran for an excessive duration, leading to a hang.
- On systems like Ubuntu 24, the loop was terminated by a SEGV_MAPERR. The existing result-checking logic in run_native_overflow incorrectly treated this SEGV_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 in exeinvoke.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 single while loop whose condition correctly handles both the initial overflow check and the subsequent verification of guard page removal:

void do_overflow(){
  volatile int *p = NULL;
  // The loop condition is true if:
  // 1. It's the first run (_kp_rec_count == 0), causing the loop to run until SIGSEGV.
  // 2. It's the second run (_kp_rec_count > 0) AND the current allocation depth (_rec_count)
  //    is less than the depth that previously caused SIGSEGV (_kp_rec_count).
  while (_kp_rec_count == 0 || _rec_count < _kp_rec_count) {
    _rec_count++;
    p = (int*)alloca(128);
    _peek_value = p[0]; // Ensure memory is touched to trigger guard page if active
  }
  // - On the first run, this point is never reached due to longjmp from the signal handler.
  // - On the second run, if no SIGSEGV occurs, the loop completes when _rec_count == _kp_rec_count.
}

Impact and Clarity of Test Outcome with This Change:

Prevents Hangs: The primary impact of this change is the elimination of the potential for an infinite (or excessively long) loop during the second phase of 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.
Deterministic Execution of do_overflow: The do_overflow function will now consistently:
- In the first run: Execute until a SIGSEGV occurs and longjmp is called.
- In the second run: Execute allocations up to _kp_rec_count times. If no SIGSEGV occurs, it will complete this bounded loop and return normally. If a SIGSEGV 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

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8303612: runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code 139 (Bug - P3)

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

Using Webrev

Link to Webrev Comment

… with exit code 139 replace infinite loop with conditional in do_overflow function

bridgekeeper · 2025-06-09T06:54:22Z

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 /signed in a comment in this pull request.

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 /covered in a comment in this pull request.

openjdk · 2025-06-09T06:54:42Z

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

openjdk · 2025-06-09T06:55:21Z

@mz1999 The following label will be automatically applied to this pull request:

hotspot-runtime

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

sendaoYan · 2025-06-10T00:57:43Z

The copyright year should be updated from 2023 to 2025.

- Change copyright year from 2023 to 2025 in the test file header

mz1999 · 2025-06-10T06:12:56Z

The copyright year should be updated from 2023 to 2025.

Done. Updated the copyright year to 2025 as requested. Thanks!

mz1999 · 2025-06-10T06:27:42Z

/signed

bridgekeeper · 2025-06-10T06:27:56Z

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!

bridgekeeper · 2025-07-08T09:47:12Z

@mz1999 This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

mz1999 · 2025-07-08T10:05:28Z

/touch

openjdk · 2025-07-08T10:06:20Z

@mz1999 The pull request is being re-evaluated and the inactivity timeout has been reset.

mz1999 · 2025-07-09T01:41:17Z

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: [email protected]

Any help would be greatly appreciated. Thank you!

mlbridge · 2025-08-04T18:47:44Z

Webrevs

00: Full (01912a33)

dholmes-ora · 2025-08-05T02:28:41Z

@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

jdksjolen · 2025-08-05T07:26:11Z

Hi!

I've never seen a CentOS 7 error nor an Ubuntu error, where does this come from? This issue was created before the forever-loop was introduced, where we had this:

void do_overflow(){
  int *p = alloca(sizeof(int));
  if (_kp_rec_count == 0 || _rec_count < _kp_rec_count) {
      _rec_count ++;
      do_overflow();
  }

But that's the, morally, same code as you've added back. So, did the 'hardening' fix the original bug, but introduce a new bug? Isn't exit code 139 a SIGSEGV, so does this change a different type of bug?

Thanks.

jdksjolen · 2025-08-25T18:14:38Z

Ping @mz1999

mz1999 · 2025-08-26T11:02:21Z

Hi @dholmes-ora and @jdksjolen ,

Apologies for the delayed response.

Thank you for the comments. I wasn't aware of the historical context behind this test and the changes from JDK-8295344. My investigation started simply because I observed that the test behaved differently on two platforms. To help clarify what I'm seeing, let me walk you through my testing process with the original, unmodified exeinvoke.c code.

I reverted my local changes and ran the test on both Ubuntu 24 and CentOS 7.

Test Environments

Component	Ubuntu 24.04 LTS	CentOS 7.9.2009
OS Release	Ubuntu 24.04.3 LTS	CentOS Linux release 7.9.2009 (Core)
Kernel	6.8.0-78-generic	3.10.0-1160.el7.x86_64
glibc	ldd (Ubuntu GLIBC 2.39-0ubuntu8.5) 2.39	ldd (GNU libc) 2.17
GCC	gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0	gcc (GCC) 13.2.0

Test on Ubuntu 24.04 LTS

I ran the test using the following command to retain all test artifacts:

make test TEST="test/hotspot/jtreg/runtime/StackGuardPages/TestStackGuardPagesNative.java" JTREG="RETAIN=all"

The test passed successfully. The TestStackGuardPagesNative.jtr file shows:

...
----------System.out:(8/626)----------
[2025-08-26T07:35:59.646208363Z] Gathering output for process 379416
[2025-08-26T07:35:59.656232016Z] Waiting for completion for process 379416
[2025-08-26T07:35:59.656384019Z] Waiting for completion finished for process 379416
Output and diagnostic info for process 379416 was saved into 'pid-379416-output.log'
[2025-08-26T07:35:59.658186828Z] Gathering output for process 379439
[2025-08-26T07:35:59.658413390Z] Waiting for completion for process 379439
[2025-08-26T07:35:59.677953883Z] Waiting for completion finished for process 379439
Output and diagnostic info for process 379439 was saved into 'pid-379439-output.log'
----------System.err:(3/35)----------

JavaTest Message: Test complete.

result: Passed. Execution successful


test result: Passed. Execution successful

To understand how it passed, I examined the native process log for the test_native_overflow_initial scenario (pid-379439-output.log):

--- ProcessLog ---
cmd: /home/mazhen/works/jdk/build/linux-x86_64-server-release/images/test/hotspot/jtreg/native/invoke test_native_overflow_initial
exitvalue: 0
stderr: 
stdout: Test started with pid: 379439
Java thread is alive.

Testing NATIVE_OVERFLOW
Testing stack guard page behaviour for initial thread
run_native_overflow 379439
Got SIGSEGV(2) at address: 0x7fff45e5fff0
Test PASSED. Got access violation accessing guard page at 7104
Got SIGSEGV(1) at address: 0x7fff4575bf80
Test PASSED. No stack guard page is present. SIGSEGV(1) at 58191

The log shows that the second do_overflow call for the initial thread was terminated by a SIGSEGV(1) (SEGV_MAPERR). This observation prompted me to think about what the test's true intent might be.

Of course, this is just my interpretation, and I may be mistaken. From my reading, the test is designed as a two-phase process:

Probe: The first do_overflow call finds the exact allocation depth (_rec_count) that triggers the SEGV_ACCERR from the guard page.
Verify: The second do_overflow call should then confirm that after detaching the thread, it's safe to allocate up to that same depth again, this time completing without any signal.

A true "pass" for this verification should therefore correspond to the _last_si_code == -1 check in the code, which explicitly handles the "no signal" scenario.

} else if (_last_si_code == -1) {
      printf("Test PASSED. No stack guard page is present. Maximum recursion level reached at %d\n", _rec_count);
}

However, the current test passes on Ubuntu not for this reason, but because the second overflow attempt is coincidentally terminated by a different signal, a SEGV_MAPERR. This shows that the test is not passing as intended.

2. Test on CentOS 7 (Hangs and Times Out)

Running the same test on CentOS 7 resulted in a timeout after 480 seconds. The TestStackGuardPagesNative.jtr file shows:

...
----------System.out:(6/436)----------
[2025-08-26T09:40:07.939476649Z] Gathering output for process 323
[2025-08-26T09:40:07.959566183Z] Waiting for completion for process 323
[2025-08-26T09:40:08.082615370Z] Waiting for completion finished for process 323
Output and diagnostic info for process 323 was saved into 'pid-323-output.log'
[2025-08-26T09:40:08.095675574Z] Gathering output for process 344
[2025-08-26T09:40:08.096106994Z] Waiting for completion for process 344
result: Error. "main" action timed out with a timeout of 480 seconds on agent 2


test result: Error. "main" action timed out with a timeout of 480 seconds on agent 2

I checked the test artifacts. The log for the test_native_overflow (non-initial thread) scenario, pid-323-output.log, was generated and showed a pass, as expected:

--- ProcessLog ---
cmd: /root/jdk/build/linux-x86_64-server-release/images/test/hotspot/jtreg/native/invoke test_native_overflow
exitvalue: 0
stderr: 
stdout: Test started with pid: 323
Java thread is alive.

Testing NATIVE_OVERFLOW
Testing stack guard page behaviour for other thread
run_native_overflow 342
Got SIGSEGV(2) at address: 0x2b4fffc94fb0
Test PASSED. Got access violation accessing guard page at 7137
Test PASSED. Not initial thread

However, the log for the failing test_native_overflow_initial scenario was not generated at all. This strongly suggests the process hung indefinitely in the for(;;) loop and was terminated before it had a chance to flush its output.

Moving Forward

Your comments have been incredibly helpful. They've made me realize that this issue is far more complex than I first understood. My initial PR was focused squarely on fixing the hang symptom I observed on CentOS 7.

I will need to do some further investigation to fully understand the original problem that the for(;;) loop was intended to solve.

Thank you again for your guidance and patience.

dholmes-ora

I think this fix addresses your CentOS timeout issue by ensuring that the overflow loop will terminate even if no SEGV is encountered. IIUC "normally" the peek would eventually fault when we hit the libc guard page, but on CentOS this may not be the case and the region beyond the current stack may be accessible and so not fault.

However, I don't see how this fix addresses the other failure modes that have been reported in this issue.

mz1999 · 2025-08-28T07:44:20Z

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.

dholmes-ora · 2025-08-29T02:11:19Z

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

I agree this continues to fix the problem seen with the recursive approach. I also agree it should fix the CentOS hang.

However, I do not see how this will address the actual failure that is reported in JBS for this issue:

Testing NATIVE_OVERFLOW
Testing stack guard page behaviour for other thread
run_native_overflow 1281626
Got SIGSEGV(2) at address: 0xffff8daf3fa0
Test PASSED. Got access violation accessing guard page at 7983
Test PASSED. Not initial thread
];
stderr: []
exitValue = 139

The JBS connections and timeline is very hard to follow, but I believe this failure was seen after the hardening fix had been applied.

mz1999 · 2025-08-29T10:45:59Z

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

I agree this continues to fix the problem seen with the recursive approach. I also agree it should fix the CentOS hang.

However, I do not see how this will address the actual failure that is reported in JBS for this issue:

Testing NATIVE_OVERFLOW Testing stack guard page behaviour for other thread run_native_overflow 1281626 Got SIGSEGV(2) at address: 0xffff8daf3fa0 Test PASSED. Got access violation accessing guard page at 7983 Test PASSED. Not initial thread ]; stderr: [] exitValue = 139

The JBS connections and timeline is very hard to follow, but I believe this failure was seen after the hardening fix had been applied.

Thank you for your patience and for pointing out the discrepancy. You were absolutely right to question how my PR addressed the failure mode in the JBS issue. After re-evaluating everything, I realize I have made a mistake and confused two separate issues. I sincerely apologize for the noise and for taking up your valuable time.

Let me clarify what happened. The JBS issue associated with this PR, JDK-8303612, describes a failure where the Not initial thread test passes but the process exits with code 139.

However, the problem I have been trying to solve is a timeout hang that occurs specifically in the "initial thread" scenario.

My investigation started when I encountered this hang while running the jdk17u test suite on CentOS 7. The test timing out and ultimately reporting an error led me to incorrectly associate my hang with JDK-8303612, as on the surface they appeared to be related failures.

To confirm this, I re-ran the tests from the jdk17u repository on my CentOS 7 environment today. The relevant TestStackGuardPagesNative.jtr output is:

[2025-08-29T06:47:50.718385554Z] Gathering output for process 29415
[2025-08-29T06:47:50.741718596Z] Waiting for completion for process 29415
[2025-08-29T06:47:50.826107509Z] Waiting for completion finished for process 29415
Output and diagnostic info for process 29415 was saved into 'pid-29415-output.log'
[2025-08-29T06:47:50.833637359Z] Gathering output for process 29434
[2025-08-29T06:47:50.834255494Z] Waiting for completion for process 29434
[2025-08-29T06:56:22.496916196Z] Waiting for completion finished for process 29434
Output and diagnostic info for process 29434 was saved into 'pid-29434-output.log'
STDERR:
 stdout: [Test started with pid: 29434
Java thread is alive.
];
 stderr: []
 exitValue = 134

java.lang.RuntimeException: Expected to get exit value of [0]

	at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:504)
	at TestStackGuardPagesNative.main(TestStackGuardPagesNative.java:49)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
	at java.base/java.lang.Thread.run(Thread.java:840)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down test


TEST RESULT: Error. "main" action timed out with a timeout of 480 seconds on agent 2

The logs confirm that the Not initial thread test (pid-29415) completes successfully, while the "initial thread" test (pid-29434) hangs until the test harness kills it.

This is fundamentally different from the teardown crash described in JDK-8303612.

Again, my apologies for the confusion I've caused. I will take some more time to reconsider the best path forward. If I cannot find a way to contribute that cleanly addresses a well-defined issue, it would be better to maintain the status quo.

Thank you again for your time and guidance.

dholmes-ora · 2025-09-01T04:32:05Z

I would suggest filing a new bug for the CentOS hang and create a new PR of the change here, with that new bug ID.

mz1999 · 2025-09-03T10:07:28Z

I would suggest filing a new bug for the CentOS hang and create a new PR of the change here, with that new bug ID.

Thank you, that plan sounds great.

I don't yet have an account on bugs.openjdk.org to file the new bug.

Would you mind creating the JBS issue for this hang? I've drafted all the necessary information below to help.

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

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

Uh oh!

Conversation

mz1999 commented Jun 9, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewing

Uh oh!

bridgekeeper bot commented Jun 9, 2025

Uh oh!

openjdk bot commented Jun 9, 2025

Uh oh!

openjdk bot commented Jun 9, 2025

Uh oh!

sendaoYan commented Jun 10, 2025

Uh oh!

mz1999 commented Jun 10, 2025 • edited by bridgekeeper bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mz1999 commented Jun 10, 2025

Uh oh!

bridgekeeper bot commented Jun 10, 2025

Uh oh!

bridgekeeper bot commented Jul 8, 2025

Uh oh!

mz1999 commented Jul 8, 2025

Uh oh!

openjdk bot commented Jul 8, 2025

Uh oh!

mz1999 commented Jul 9, 2025

Uh oh!

mlbridge bot commented Aug 4, 2025

Webrevs

Uh oh!

dholmes-ora commented Aug 5, 2025

Uh oh!

jdksjolen commented Aug 5, 2025

Uh oh!

jdksjolen commented Aug 25, 2025

Uh oh!

mz1999 commented Aug 26, 2025

Test Environments

Test on Ubuntu 24.04 LTS

2. Test on CentOS 7 (Hangs and Times Out)

Moving Forward

Uh oh!

dholmes-ora left a comment

Choose a reason for hiding this comment

Uh oh!

mz1999 commented Aug 28, 2025

The Original Recursive Implementation

The "Hardening" Fix (Iterative but Unbounded)

My Proposed Change (Iterative and Bounded)

Uh oh!

dholmes-ora commented Aug 29, 2025

Uh oh!

mz1999 commented Aug 29, 2025

Uh oh!

dholmes-ora commented Sep 1, 2025

Uh oh!

mz1999 commented Sep 3, 2025

Suggested JBS Issue Content

Uh oh!

sendaoYan commented Sep 3, 2025

Uh oh!

mz1999 commented Sep 5, 2025

Uh oh!

Uh oh!

mz1999 commented Jun 9, 2025 •

edited by openjdk bot

Loading

mz1999 commented Jun 10, 2025 •

edited by bridgekeeper bot

Loading