RFR: 8304147: JVM crash during shutdown when dumping dynamic archive
David Holmes
dholmes at openjdk.org
Wed Mar 22 22:02:44 UTC 2023
On Wed, 22 Mar 2023 21:32:15 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:
>> `DynamicArchive::prepare_for_dump_at_exit()` could be called concurrently on the two VM exit paths, leading either to assertion failures in debug builds, or a crash in product build when the actual dump occurred. The basic fix was to move the `DynamicArchive::prepare_for_dump_at_exit()` functionality into `before_exit` (java.cpp) where it can only be executed by one thread - thus avoiding the race (Phase 1).
>>
>> Once that is done we can move the actual dump operation to be co-located with the `prepare_for_dump_at_exit()` (Phase 2) and then consolidate that code by refactoring it into a new `DynamicArchive::dump_at_exit()` method (Phase 3), and then removing the leftover methods that are no longer needed (Phase 4).
>>
>> Each phase can be seen in distinct commits if you prefer to see the steps involved.
>>
>> Testing:
>> - new ExitRace test
>> - all dynamicArchive tests
>> - tiers 1-4
>>
>> Thanks.
>
> src/hotspot/share/runtime/javaThread.cpp line 2031:
>
>> 2029: if (this->has_pending_exception()) {
>> 2030: this->clear_pending_exception();
>> 2031: }
>
> I think the HandleMark can be removed.
> We may need to move lines 2026 - 2031 to the new `dump_at_exit` function.
Thanks missed that. Not sure how we can get here with a pending exception though:
DestroyJavaVM()
-> Threads::destroy_vm();
-> wait till last non-daemon thread
-> commit shutdown event
-> JavaThread::invoke_shutdown_hooks()
There is nowhere for an exception to materialize in this path AFAICS.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1145449729
More information about the hotspot-runtime-dev
mailing list