RFR(XS): 8143897 :Weblogic12medrec assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same

[Jamsheed C m]

Hi Dean,

On 1/30/2016 12:49 AM, Dean Long wrote:
> On 1/28/2016 10:36 PM, Jamsheed C m wrote:
>> Hi Dean,
>>
>> On 1/29/2016 9:40 AM, Dean Long wrote:
>>> As you noticed, for this kind of bug the memory is going to 
>>> consistent by the time the core file is written.
>>> So to help debug this assert it if happens again, could you change 
>>> it to something like:
>>>
>>> #ifdef ASSERT
>>>     address computed_address = 
>>> SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, 
>>> force_unwind, true);
>>>     vmassert(handler_address == computed_address, PTR_FORMAT " != " 
>>> PTR_FORMAT, p2i(handler_address), p2i(computed_address));
>>> #endif
>> I got handler_address value in this case. This value was inconsistent 
>> with value in ExceptionCache.
>> It was having initial value and that was helpful in figuring out what 
>> would have went wrong.
>>
>
> In the bug report, you said all data in the core file was consistent, 
> so I'm just wondering where you saw
> it inconsistent.   Just to confirm what was going wrong, you suspect 
> that _count was being updated before the handler?
i meant ExceptionCache(heap) and ExecptionHandlerTable(heap) contents 
were consistent at the time core file was written.
handler_address(local variable) had already captured failing value. 
handler_address(local variable) was inconsistent with 
ExceptionCache(heap) hanlder_address in core file.

there were two failing case.
1) Only one entry in exception cache and failing

         -here i suspect handler_address in exception cache write code 
got reordered well below count and and even ExceptioCache pointer update 
in nm.
2)Two entries in exception cache for an exception and second entry 
causing failure.

         - here i suspect handler_address in exception cache write code 
got reordered below count.

These reordering happens in very small window, as this is code is 
already lock protected ( and has a mem barrier below).

Best,
Jamsheed

>
> dl
>
>> I will make this change.
>>
>> Best Regards,
>> Jamsheed
>>>
>>> dl
>>>
>>> On 1/28/2016 8:16 AM, Jamsheed C m wrote:
>>>> Hi,
>>>>
>>>> Please review the fix made for issue
>>>>
>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8143897
>>>> web rev: http://cr.openjdk.java.net/~thartmann/8143897/webrev.00/
>>>>
>>>> Unit tests: As its hard, none
>>>>
>>>> Other tests: jprt.
>>>>
>>>> Description of the issue:
>>>> A valid pc match in exception cache returning an invalid handler 
>>>> makes assert to fail.
>>>> This happens as  ExceptionCache reads are lock free access.
>>>>
>>>> As a fix for this i have put a storestore mem barrier before the 
>>>> count is updated.
>>>>
>>>> Best Regards,
>>>> Jamsheed
>>>
>>
>