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

[KEVIN WALLS]

Thanks!

On 03/12/2014 19:50, Staffan Larsen wrote:
> I agree. Go ahead with this and hopefully we can revisit it later.
>
> Thanks,
> /Staffan
>
>> On 3 dec 2014, at 17:17, KEVIN WALLS <kevin.walls at oracle.com> wrote:
>>
>> Thanks Staffan -
>>
>> Yes, I've updated it to be simply canAttachOSX().  Seems likely we should go ahead with that and possibly revisit the OSX conditions, good to have the method there so we can make it more complete and complex later when/if required.  Right now, I think this is suitable for our automated tests, it could be that we are stopping people (you? 8-) ) running this automated test as a non-root user, such tests will not execute, but shouldn't fail...
>>
>> Thanks
>> Kevin
>>
>>
>> On 03/12/2014 12:53, Staffan Larsen wrote:
>>>   178     public static boolean canPtraceAttachOSX() throws Exception {
>>>   179         return userName.equals("root");
>>>   180     }
>>>
>>> Ptrace isn’t the API that is doing the most vigorous access checks on OS X. Instead the system call task_for_pid() is what causes most of the access denied problems. So perhaps just skipping the “Ptrace” part of the method name above is good.
>>>
>>> Then, on OS X again, the root user will indeed av access to other processes, but it’s not the only way. A regular user can also get access if a couple of prerequisites are met:
>>> 1) The attaching program is compiled with SecTaskAccess=allowed in Info.plist. We do this for jstack, jinfo and jmap.
>>> 2) The attaching program is signed.
>>> 3) The user has given permission for taking control of another process via a dialog box that OS X displays.
>>> (I think these are all…)
>>>
>>> Regarding signing above: Oracle signs binaries that we ship with an official certificate, but development binaries are also signed if a certificate called openjdk_codesign is found on the machine where the product is built. Usually one creates a self-signed such certificate if one wants to test the attaching functionality.
>>>
>>> All this to say that if we only check for root, then it will not be possible to run the tests as a regular user even if you have done 1-3 above. That would be a shame, but perhaps cannot be avoided given the complexity involved.
>>>
>>> /Staffan
>>>
>>>
>>>> On 26 nov 2014, at 14:53, KEVIN WALLS <kevin.walls at oracle.com> 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