RFR(S) 8161225: Assert failure in JVMTI GetNamedModule at JPLISAgent.c line: 792
Chris Plummer
chris.plummer at oracle.com
Thu Sep 22 02:03:25 UTC 2016
On 9/21/16 9:33 AM, Chris Plummer wrote:
> On 9/21/16 7:33 AM, Daniel D. Daugherty wrote:
>> On 9/20/16 11:07 PM, Chris Plummer wrote:
>>> Hello,
>>>
>>> Please help review the following:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8161225
>>> http://cr.openjdk.java.net/~cjplummer/8161225/webrev.00/
>>
>> hotspot/src/share/vm/prims/jvmtiEnter.xsl
>> L490: log_trace(jvmti)("[-] %s %s(%d)", func_name,
>> nit: extra space after the comma
>> nit: extra space at the end of the line
> Those were both pre-existing, but I'll clean them up.
>>
>> jdk/src/java.instrument/share/native/libinstrument/JPLISAgent.c
>> No comments.
>>
>> jdk/test/ProblemList.txt
>> No comments.
>>
>> jdk/test/java/lang/instrument/DaemonThread/TestDaemonThreadLauncher.java
>> I presume when you change the assertTrue() call to an
>> OutputAnalyzer.should...() call that the new import can
>> be deleted.
> Correct. I have removed it and it still compiles.
>>
>> One thing that wasn't clear from your write up below... when you detect
>> a PHASE error, you now return a NULL (but the code is clear).
> Yep.
Actually it always returned NULL when there was a PHASE error because
moduleObject would still be NULL. The only difference now is you don't
get the jplis_assert_msg() call, which is really just a printf.
Chris
>>
>> Thumbs up. Don't need to see a new webrev for fixing any nits.
> Thanks for the review.
>
> Chris
>>
>> Dan
>>
>>
>>>
>>> The main fix is in JPLISAgent.c, which is to no longer call
>>> jplis_assert_msg() when there is a PHASE error, and also remove the
>>> test from ProblemList.txt.
>>>
>>> I also fixed a problem with the test. It was not checking if the
>>> subprocess had failed to terminate properly. The result was if the
>>> sub-process crashed, then the test would pass. I noticed this when I
>>> temporarily forced an assert when there was a PHASE error, and
>>> suddenly the test was always passing, yet there was an hs_err.log file.
>>>
>>> Lastly, I made a slight improvement to the trace output when there
>>> is a PHASE error, so now the PHASE number is included in the trace
>>> output. So the trace output now looks like the following when the
>>> test triggers the PHASE error (this is without the fix being made to
>>> the test):
>>>
>>> [0.376s][trace][jvmti] [-] GetNamedModule
>>> JVMTI_ERROR_WRONG_PHASE(8)
>>>
>>> Tested by running the test 5 times on each supported platform, and
>>> also ran nsk.jvmti and jck/vm/jvmti.
>>>
>>> thanks,
>>>
>>> Chris
>>
>
More information about the hotspot-runtime-dev
mailing list