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