RFR: 8355225: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm: apparent log corruption

[Johan Sjölen]

Hi,

We've intermittently seen failures from this test. The testing of the actual semantics of dropping async messages is done throughout the entire test file, and then we have a specific test called `droppingMessage`. Certainly, this is a bit unexpected, and perhaps not what we want. What I did find, however, is that this test doesn't follow the same pattern as the other ones that do the drop message testing.

The other tests do:


    test_asynclog_drop_messages();
    AsyncLogWriter::flush(); // <- Insert a flush token to the AsyncLogWriter buffer and await for it to be written
    fflush(nullptr); // <- Force all libc writes to be performed


And the `droppingMessage` test only does `test_asynclog_drop_messages();` .

I'd like us to just insert these two lines and see whether this affects what we see in our testing. This doesn't explain the so-called 'log corruption' when we try to read the content. The best explanation (read: guess) I have for that is that we're concurrently reading and writing to the file, and this leads to data races between the reads and writes.

Thanks.

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

Commit messages:
 - Flush and log

Changes: https://git.openjdk.org/jdk/pull/28374/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28374&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355225
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28374.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28374/head:pull/28374

PR: https://git.openjdk.org/jdk/pull/28374