Hi Jc,
This looks good to me especially because we discussed it a lot
internally.
The testing looks pretty good too.
I submitted mach5 jobs for HepMonitor tests repeating 100 times
and also normal tier1, tier2, hs-tier2-5.
But it was not tested with the tiers 6 & 7 yet (most likely,
need to make sure they run well too).
Thanks,
Serguei
On 8/6/18 08:27, JC Beyler wrote:
Hi all,
I updated the version and Serguei tested it for me so this
change should not change the stability of the tests. This has
the advantage of not having to complicate the Java tests at
all, while adding the post-JNI call checks.
Thanks all for your reviews!
Jc
Hi all,
I did the new version that calls FatalError if JNI
fails a call. This has the advantage of not having to
complicate the Java tests at all, while adding the
post-JNI call checks.
Thanks all!
Jc
I'm
pretty sure changes that only affect tests can be any
priority. But still, be a lot more cautious the closer
we get to release.
Chris
On 7/26/18 12:15 PM, Daniel D. Daugherty wrote:
We entered RDP2 today
(07.26). So only P1 and P2 bug fixes allowed.
Dan
Yes,
of course it has to be well tested before the
push.
Does it make sense to plan it to push to 11 (after
th testing is done)?
Thanks,
Serguei
On 7/26/18 12:08, Daniel D. Daugherty wrote:
Please make sure this
fix is well tested in Mach5 prior to pushing.
In particular, I'm focused on reducing the noise
in Mach5 tier[1-3]
so adding any new failures there will make me
grumpy :-)
Dan
On
7/26/18 3:03 PM, JC Beyler wrote:
Hi all,
With the FatalError idea, here is the
webrev to consider, note it no longer
changes the tests. If a JNI call fails, then
we call FatalError.
Let me know what you think:
Thanks!
Jc
Hi
Jc,
Good idea.
I was thinking about something like
this.
Thanks,
Serguei
On 7/26/18 10:40, JC Beyler wrote:
Hi Serguei,
If we went down that route, this
webrev is simpler, no? Instead of
setting failure_status and checking
it later; just fail fatally and be
done with it, no? That way, the
tests in Java land don't have to be
changed actually, no?
What would we prefer for tests?
Remember there was a failure and
test it later or fail fast via JNI's
FatalError?
Thanks,
Jc
Hi
Jc,
It looks good to me.
Thanks,
Serguei
On 7/26/18 09:58, JC Beyler
wrote:
Hi all,
The tests in the
HeapMonitor subsystem has a
lot of JNI calls. There is a
need for verification and
testing if anything in the
JNI subsystem failed
unexpectedly.
Here is a webrev that
tracks if a JNI call does
fail and the tests will fail
if any JNI call does fail.
Could I have a few
reviews please for:
--
--
--
--
|