Initial triage of JFR nighly regressions + bugster bugs

[serguei.spitsyn at oracle.com]

Vladimir and Nicolay,

Just wanted to let you know about several new bugs opened in the 
hotspot/test category.
They are behalf of the JFR_Baseline nightly and need to be resolved 
quicker than usually,
so the priority is P3. It is because the JFR needs better test coverage.
Please, let us know if you disagree.

I've just moved to the hotspot/test subcat the bug:
     7130996 nsk/jvmti/RedefineClasses/redefclass031 fails with JFR

Also, I've opened another one (covers 3 nsk/jvmti tests: popframe001, 
popframe003, popframe005):
   7131317 JVMTI: nsk/jvmti/PopFrame/popframe003 fails intermittently 
with JFR

The bug 7130996 does not have a suggested fix but the approach can be 
the same -
to filter out the NativeMethodBind events coming from unexpected threads 
(JFR thread in our case).

Thanks,
Serguei


On 1/18/12 12:21 PM, Markus Grönlund wrote:
>
> Hi Serguei,
>
> I think Nils has setup a new system for JFR binaries (and included 
> them into JRPT install) although I have not tried it yet. I will try 
> to find the mail from Nils, otherwise he will see this tomorrow 
> Swedish time for clarification.
>
> Your list looks accurate from what we filed today!
>
> Thanks a lot!
>
> Markus
>
> *From:*Serguei Spitsyn
> *Sent:* den 18 januari 2012 20:55
> *To:* Markus Grönlund
> *Cc:* jfr_dev_ww
> *Subject:* Re: Initial triage of JFR nighly regressions + bugster bugs
>
> Hi Markus,
>
> This is the list I've got:
>   7130983 Test failures in nsk/sajdi/
>   7130988 nsk/hprof/options/depth/depth002 fails in JFR_Baseline
>   7130989 nsk/hprof/options/format/format002 fails with JFR
>   7130990 nsk/jdi/ReferenceType/allFields/allfields005 fails with JFR: 
> assertion JNI handle should not be null
>   7130992 Test failures in nsk/jdb (esp on Win-i586)
>   7130993 nsk/jdi/ReferenceType/instances/instances004 fails with JFR: 
> assert(ServiceUtil::visible_oop(obj))
>   7130995 tests in nsk/regression/ fail on win-i586
>   7130996 nsk/jvmti/RedefineClasses/redefclass031 fails with JFR
>   7131001 Test failure in nsk/regression/b6186200
>   7131006 java/lang/management/ThreadMXBean/ThreadLists.java
>
>
> These are current test-fail-jfr bugs that was already routed to SQE:
>   7122951 JVMTI: nsk/jvmti/scenarios/multienv/MA10/ma10t001 fails when 
> JFR is enabled
>   7122954 JVMTI: nsk/jvmti/ClassPrepare/classprep001 fails when JFR is 
> enabled
>   7131002 com/sun/jdi/InstanceFilter.java fails with JFR: Does not 
> expect MethodEntryEvent from JFR
>   7131005 com/sun/jdi/MethodExitReturnValuesTest.jav fails with JFR: 
> Does not expect events from JFR Thread
>   7131007 demo/jvmti/mtrace/TraceJFrame.java fails in JFR_Baseline: 
> Can't connect to X11 server
>
>
> How are we supposed to find the latest JFR jdk binaries that was used 
> in nightly?
>
> Thanks,
> Serguei
>
>
>
> On 1/18/12 9:02 AM, Markus Grönlund wrote:
>
> Hi all,
>
> Myself and Rickard spent the day trying to understand the reporting of 
> nightly failures for JFR_Baseline with an ambition to bring in some 
> descriptions for the failures into Bugster, as well as starting to 
> learn on how to use UTE to address test failures.
>
> We have made a first stab at this with a few bugster bugs outlining 
> what we found -- I still don't know how to post a query to bugster, 
> but if you search for manager tuva.palm at oracle.com 
> <mailto:tuva.palm at oracle.com> you can get to see them (they are also 
> tagged with keyword test-fail-jfr.
>
> We need to address the failures here; a lot of them seems to be 
> related to environmental setups but a few seems to be related to tests 
> that needs to be updated (and bugs re-routed to SQE?).
>
> We have asked SQE to turn JFR defaultrecording back ON as of tonight, 
> so hopefully we will have some additional information/failures to 
> triage tomorrow.
>
> Please take  a look at the bugs if you can -- I am in the process of 
> trying to rule out a lot of the failures for Windows fiddling around 
> in UTE...
>
> Thanks a lot
>
> Markus
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120119/8e9c53f8/attachment-0001.html