[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8039995: Test serviceability/sa/jmap-hashcode/Test8028623.java
From:       Kevin Walls <kevin.walls () oracle ! com>
Date:       2014-05-24 18:25:42
Message-ID: 5380E426.5080904 () oracle ! com
[Download RAW message or body]


Thanks Peter, and thanks Dmitry -

So another thread on this has started about why such a test runs in an 
environment that can't expected to attach to its own processes anyway: 
seems that some test systems permit that, and some run as a user that 
can't necessarily expect to have that ability.

(Dmitry I'm not sure about exiting with that error value?  If that's 
something people are meant to know about I have missed it. But the test 
would fail if jmap didn't create the heap dump file, i.e. if it fails 
but doesn't exit with the right code.)

For the moment I'll wait on that other information for whether this 
needs to be fixed in the test...

Thanks!
Kevin




On 23/05/14 12:00, Peter Allwin wrote:
> Looks good to me!
> 
> 
> Thanks for looking at this Kevin,
> /peter
> 
> On 20 May 2014, at 13:14, Kevin Walls <kevin.walls@oracle.com> wrote:
> 
> > Hi - any comments? 8-)
> > 
> > On 12/05/14 16:02, Kevin Walls wrote
> > > Hi,
> > > 
> > > I'd like to get a review of this test change.  It assumed that jmap would have \
> > > permission to run on a process that the test itself created, but this is not \
> > > necessarily the case. 
> > > Here I'm considering it OK to skip (pass) the test where jmap fails to attach.  \
> > > The test itself was not platform-specific and as long as we have other \
> > > platforms where jmap step will work, we are testing for this problem. 
> > > bug:
> > > https://bugs.openjdk.java.net/browse/JDK-8039995
> > > 
> > > webrev:
> > > http://cr.openjdk.java.net/~kevinw/8039995/webrev.00/
> > > 
> > > Thanks
> > > Kevin


[prev in list] [next in list] [prev in thread] [next in thread]