RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text

[Tyler Steele]

On Mon, 4 Apr 2022 15:47:06 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX.
> 
> The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. 
> 
> A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result.
> 
> ### Testing
> 
> Tier1 tests complete as expected on AIX/Power.

Hi Thomas,

> in the JVM we have `VMError::segfault_address` for this reason. I'd prefer if we reused that (publishing it via Whitebox method) instead of polluting the shared tests with PPC specifics. We could reuse this whitebox method in other tests, actually, without running into the NULL-is-readable issue again.
>
> (To see how whitebox methods are used, see the classes in sun.hotspot.WhiteBox and their corresponding "WB_..." endpoints in hotspot/share/prims/whitebox.cpp. Its all pretty straightforward).

I like this idea. It's not really reasonable to expect that everyone will keep track of all the little nuances between the different systems, and it's easier if we solve the problem one way and use it in multiple places. I will take a look at this.

> Another, maybe simpler option would be just to write instead of read in `crashInNative3`. crashInJava3 uses write too (putLong). But it looks deliberate, so you'd have to look at the original RFR for this test.

Tried that ;-) Your intuition is good; the crash produces slightly different output than the test expects.

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

PR: https://git.openjdk.java.net/jdk/pull/8094