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

[Tyler Steele]

On Wed, 20 Apr 2022 17:39:16 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. [Edit: The changes made to `extractFrames` are now minimal. I made the change to `AixNativeCallstack::print_callstack_for_context` instead.]
>> 
>> 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.
>
> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Test: Sample error with no printing should print hs_err output"
>    
>    This reverts commit 6c70a45d862c1aa26d9c4d585bf8ecd39892e3bb.
>  - Adds logging to stdout/stderr to prevent too-long Exception messages.

test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 185:

> 183:             }
> 184:         }
> 185:         System.err.println(hsErr);

It's a popular (and reasonable) [question](https://github.com/openjdk/jdk/pull/8094#discussion_r852787701) as to why I made the change to the exception reporting. This is the error that resulted from a too-long exception message.


java.io.UTFDataFormatException: encoded string (`main' t....11 END.) too long: 116222 bytes
        at java.base/java.io.DataOutputStream.writeUTF(DataOutputStream.java:369)
        at java.base/java.io.DataOutputStream.writeUTF(DataOutputStream.java:333)
        at com.sun.javatest.regtest.agent.AgentServer.writeStatus(AgentServer.java:351)
        at com.sun.javatest.regtest.agent.AgentServer.doMain(AgentServer.java:307)
        at com.sun.javatest.regtest.agent.AgentServer.run(AgentServer.java:233)
        at com.sun.javatest.regtest.agent.AgentServer.main(AgentServer.java:70)


This error hampered my ability to debug this test. It's not very clear from the message as to where it's coming from, and it occurs sporadically depending on the length of the message produced. I eventually traced it to the line: `throw new RuntimeException(""" + marker + "" line missing in hs_err_pid file:\n" + hsErr);`. To trigger the error for this comment, I changed `hsErr` to `hsErr + hsErr`.

This issue may be platform specific, or the issue just isn't encountered very often because it's uncommon to add > 64KiB Strings to an Exception. Either way, making this change made the test failures much easier to diagnose.

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

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