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
jamsheed.c.m at oracle.com
Sat Jan 30 04:08:44 UTC 2016
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));
>> 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
2)Two entries in exception cache for an exception and second entry
- 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).
>> I will make this change.
>> Best Regards,
>>> On 1/28/2016 8:16 AM, Jamsheed C m wrote:
>>>> 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,
More information about the hotspot-compiler-dev