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 [email protected]
<mailto:[email protected]> 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
