Since ~ 25th August we see the test TestDumpOnCrash.java failing on Linux ppc64le and Linux aarch64.
It reports the following :

Attempt 0. Verification failed:
File length 0. Should at least be some bytes: expected 0 to not equal 0
Retrying...

Attempt 1. Verification failed:
File length 0. Should at least be some bytes: expected 0 to not equal 0
Retrying...

Attempt 2. Verification failed:
File length 0. Should at least be some bytes: expected 0 to not equal 0
Retrying...

java.lang.Exception: 3 attempts with failure!
at jdk.jfr.jvm.TestDumpOnCrash.test(TestDumpOnCrash.java:118)
at jdk.jfr.jvm.TestDumpOnCrash.main(TestDumpOnCrash.java:79)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:578)
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:1589)

So 3 times an "evacuation" file of 0 bytes is reported .

The test "generates" crashes when trying to test the jfr "evacuation".
But in these crashes I notice timeouts like these :

[thread 76208 also had an error]

------ Timeout during error reporting after 120 s. ------
# [ timer expired, abort... ]


Is it maybe related to 8242181: [Linux] Show source information when printing native stack ?
That might change the crashing behavior in Linux ?
Should the timeouts be increased somehow for this test ?

The test machines showing the issue are based on SuSE SLES15 and RedHat 8 so the kernel should be not that old.