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

[Thomas Stuefe]

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.

Hi @JoKern65,

good analysis. 

The typical way to handle this is to mark a test that modifies global state with "TEST_OTHER_VM". Ideally, gtests should be executable concurrently without affecting each other (we don't do this currently and many tests are probably not clean in this way, but still.

In addition to that make any test that needs anything VMish as _VM - as you already correctly do.

Cheers, Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/16479#issuecomment-1794531180