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 at oracle.com
Fri Jan 29 19:19:16 UTC 2016
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 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