RFR: 8339159: api/java_rmi/Naming/Rebind.html crashes with SEGV from UTF8::quoted_ascii_length call

[Axel Boldt-Christmas]

On Thu, 5 Sep 2024 12:09:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a long standing bug in the symboltable=trace logging code that we just discovered because we enabled trace logging in some of our testing. The logging code is passed a Symbol that we apparently couldn't fast-free from the resource area, but in a debug build the Symbol has already been zapped and so can't be printed.
>> 
>> Testing
>>  - internal testing of the code that demonstrated the failure (but it is intermittent)
>>  - tiers 1-3 sanity
>> 
>> Thanks
>
> src/hotspot/share/classfile/symbolTable.cpp line 181:
> 
>> 179:       NOT_PRODUCT(sym = ZapResourceArea ? nullptr : &value;)
>> 180:       if (!SymbolTable::arena()->Afree(memory, alloc_size)) {
>> 181:         log_trace_symboltable_helper(sym, "Leaked permanent symbol");
> 
> Thinking more about this I'm not sure the log message is really appropriate. IIUC we haven't "leaked" anything, we just can't fast-free it. I'm not sure what the true/false return from `Afree` is really meant to signify. No other callers of `Afree` even check the return value!

Failing to Afree here leaks the memory for the lifetime of the arena (unusable for new allocations), while if it succeeds the memory can be reused during the arenas lifetime.  This arena seems to be created when we start the VM and is never reclaimed, so we effectively leak this memory.

I do not quite understand why we have a `SymbolTable::arena()`. We only seem to use the arena for the permanent symbols. But why not just allocate with malloc, and in the racy case, where we free a permanent (embedded symbol) node just call free.

Maybe there is a fear that permanent small malloc allocations would cause fragmentation. Or there is some other history here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20865#discussion_r1747233700