RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah tests [v4]

Y. Srinivas Ramakrishna ysr at openjdk.org
Fri Dec 13 00:00:36 UTC 2024


On Thu, 12 Dec 2024 23:35:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Good catch!
>
> It wasn't actually the periodic task causing the crash (though that issue has been fixed here as well). The crash was caused by the control thread trying to `ShenandoahHeap::do_gc_threads` which included the regulator thread that had already been stopped by `ShenandoahHeap::stop`. The fix here was to stop the control thread before stopping the regulator thread, thereby preventing the control thread from trying to access stopped threads.
> 
> This was fairly easy to reproduce (and verify) once I had an Alpine Linux environment set up.

In light of the new findings, should the `if` test be converted now into an `assert` of some sort about the threads not having been terminated during any test (I know the assert is still "racy" -- it doesn't cover the entire window -- but sound to call here. Also wondering if the original when run with a fastdebug build may have asserted down in the `os::` method because of finding a null `osthread`? Should the `os::` methods assert on non-nullness of associated `osthread`? Worth checking now that you have an AlpineLinux box to test on?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22693#discussion_r1883044632


More information about the shenandoah-dev mailing list