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

[Dean Long]

On 1/29/2016 9:19 PM, Jamsheed C m wrote:
>
>
> On 1/30/2016 9:38 AM, Jamsheed C m wrote:
>>
>> 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 code is 
>> already lock protected ( and has a mem barrier below).
> i have removed the ambiguity in the bug report.
>

OK thanks.  The change looks good to me.

dl

> Best Regards,
> Jamsheed
>>
>> 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
>>>>>
>>>>
>>>
>>
>