RFR: JDK-8319104: GtestWrapper crashes with SIGILL in AsyncLogTest::test_asynclog_raw on AIX opt

[Thomas Obermeier]

On Thu, 2 Nov 2023 15:51:13 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> Currently gtest/GTestWrapper.java crashes on AIX in the opt build.
> 
>  SIGILL (0x4) at pc=0x0000000000000000, pid=15598006, tid=258
> 
>  JRE version: OpenJDK Runtime Environment (22.0) (build 22-internal-adhoc.openjdk.jdk-dev)
>  Java VM: OpenJDK 64-Bit Server VM (22-internal-adhoc.openjdk.jdk-dev, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, aix-ppc64)
>  Problematic frame:
>  V [libjvm.so+0x42c9c] LogTagSet::vwrite(LogLevel::type, char const*, char*)+0x104
> 
> ### The reason for the SIGILL is the following:
> The _AsyncLogTest.asynclog_vm_ test iterates over the previously registered entries of _LogOutputList_. There it gets a Nullpointer, which it tries to use for a function call `(nullpointer)->write(...);` This results in an SIGILL.
> The first reason for this is, that the LogTagSet tests (which seem to be called beforehand only on AIX) creates such an entry with
> `ts.set_output_level(LogConfiguration::StdoutLog, LogLevel::Info);`
> The first flaw is that this entry is not removed again at the end of the test. So the VM is modified and would behave differently depending on the sequence of the test execution.
> The second flaw is that the registered _LogConfiguration::StdoutLog_ in the call above is still a nullpointer due to the fact that on AIX no VM was created before the LogTagSet tests and only a creation of a VM initializes the logConfiguration. So again the whole Gtestwrapper testsuite depends on the executable sequence of the tests. If no other test creates a vm beforehand the LogTagSet tests will fail. Again this has to be fixed by let the LogTagSet tests themself creating a VM.
> 
> ### Solution to fix all errors:
> 
> 1. Make the 1. LogTagSet test a TEST_VM test.
> 2. Clean up the _LogTagSet.is_level_ and _LogTagSet.level_for_ tests with a final `ts.set_output_level(LogConfiguration::StdoutLog, LogLevel::Off);` which will remove the entry from the LogOutputList again.

we talked about the changes, they look ok to me

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

PR Review: https://git.openjdk.org/jdk/pull/16479#pullrequestreview-1710756718