RFR: 8039995: Test serviceability/sa/jmap-hashcode/Test8028623.java fails on some Linux/Mac machines.

[KEVIN WALLS]

Thanks Dmitry and Peter!

On 03/12/2014 11:39, Dmitry Samersoff wrote:
> Kevin,
>
> Looks good for me!
>
> -Dmitry
>
> On 2014-11-26 16:53, KEVIN WALLS wrote:
>> ...and an update to the webrev in the same place that also checks the
>> SELinux deny_ptrace flag, another reason you can get a permission denied
>> error and fail the test.
>>
>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/
>>
>> Thanks
>> Kevin
>>
>>
>> On 20/11/2014 18:38, KEVIN WALLS wrote:
>>> Hi,
>>>
>>> I'm resurrecting this thread to revisit this testcase, the one that
>>> fails if not in an environment where an SA attach is permitted (which
>>> is linux systems with 1 in /proc/sys/kernel/yama/ptrace_scope, and mac
>>> systems as a non-root user).
>>>
>>> There are times when we want to check if an SA attach is likely to
>>> work, so in the following webrev I've put that in the testlibrary.
>>>
>>> In doing this I now realise that heap dumping with jmap/sa is broken,
>>> as reported in: https://bugs.openjdk.java.net/browse/JDK-8044416
>>>
>>> I won't remove the @ignore in this change, but it would make sense to
>>> me to do the fix below, including backporting to places where jmap -F
>>> still works.
>>>
>>> webrev
>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/
>>>
>>> bug
>>> https://bugs.openjdk.java.net/browse/JDK-8039995
>>>
>>> Thanks
>>> Kevin
>>>
>>>
>>>
>>>
>>> On 24/05/2014 19:25, Kevin Walls wrote:
>>>> 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 at 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
>