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]

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.

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
>>>>
>>>
>>
>