RFR: 8355225: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm: apparent log corruption
David Holmes
dholmes at openjdk.org
Tue Nov 18 20:11:09 UTC 2025
On Tue, 18 Nov 2025 15:12:16 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:
> 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.
>
> Testing: GHA
This does seem to make things more consistent. I'm also not sure it can actually exklain the observed issues though.
Thanks
-------------
Marked as reviewed by dholmes (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/28374#pullrequestreview-3479604305
More information about the hotspot-runtime-dev
mailing list