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