RFR: 8359646: C1 crash in AOTCodeAddressTable::add_C_string
Ashutosh Mehra
asmehra at openjdk.org
Tue Jun 17 14:18:31 UTC 2025
On Tue, 17 Jun 2025 02:34:24 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
> It is concurrency issue. Call to `AOTCodeAddressTable::add_C_string()` happened after checks that AOT code cache is still opened. But, because there is no synchronization, other thread (VM) closed/delete AOT code cache (after dumping) before code in `add_C_string()` accessed it.
>
> Added missed AOTCodeCStrings_lock in places where we modify, store and delete AOT strings table. Moved MutexLocker from `AOTCodeAddressTable::add_C_string()` to its caller and do additional check after it.
>
> I also noticed that we missed similar check after Compile_lock when we are storing AOT code.
>
> Tested hs-tier1-6,hs-tier10-rt,stress,xcomp
Unless I missed something, I think there is still synchronization problem between the thread adding a string to the AOTCodeCache and the thread closing the AOTCodeCache. See the following pattern of execution:
t0: Thread T1 calls add_C_string(), checks for `is_on_for_dump` which returns true
t1: Thread T2 calls close() and completes the call to finish_write()
t2: T1 acquires AOTCodeCStrings_lock and checks that _table is not null which returns true
t3: T2 clears the table and sets it to null
t4: T1 tries to call `table->add_C_string`
I think at the time of shutting down the AOTCodeCache, the thread should hold both `Compile_lock` and `AOTCodeCStrings_lock`.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/25841#issuecomment-2980562587
More information about the hotspot-compiler-dev
mailing list