RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X

[Jini George]

Hi Serguei, David,

Thank you very much for the link and your responses. I agree that the 
restoration of PT_ATTACH would have been a good very-short term solution 
if it were an integration blocker. But given that the restoration would 
be more or less a hack since PT_ATTACH has been deprecated and replaced 
by PT_ATTACHEXC, and since we have time, I think the right solution is 
to move to PT_ATTACHEXC. Sooner or later, we would have to do the switch 
anyways. Here is a snippet from the man page of ptrace() from Mac OSX 
version 10.11.6.


      PT_ATTACH     This call has been replaced with PT_ATTACHEXC.

      PT_ATTACHEXC  This request allows a process to gain control of an 
otherwise unrelated process and begin
                    tracing it.  It does not need any cooperation from 
the to-be-traced process.  In this case,
                    pid specifies the process ID of the to-be-traced 
process, and the other two arguments are
                    ignored.  This request requires that the target 
process must have the same real UID as the
                    tracing process, and that it must not be executing a 
setuid or setgid executable.  (If the
                    tracing process is running as root, these 
restrictions do not apply.)  The tracing process
                    will see the newly-traced process stop and may then 
control it as if it had been traced all
                    along. Note that this call differs from the prior 
call ( PT_ATTACH) in that signals from
                    the child are delivered to the parent as Mach 
exceptions (see EXC_SOFT_SIGNAL).


Moreover other debuggers like gdb and lldb have switched to using 
PT_ATTACHEXC. As pointed out in the link also, ptrace() on Apple has 
always been bare-bones. We need to supplement it with acquiring port 
rights to an exception port and waiting on that port where we can 
receive the Mach exception messages. My modifications are along the 
above lines.

Thank you,
Jini.

On 9/8/2017 3:33 AM, serguei.spitsyn at oracle.com wrote:
> On 9/7/17 14:39, serguei.spitsyn at oracle.com wrote:
>> On 8/25/17 02:24, serguei.spitsyn at oracle.com wrote:
>>> Hi Jini,
>>>
>>>
>>> On 8/18/17 04:00, David Holmes wrote:
>>>> Hi Jini,
>>>>
>>>> Just reading the bug report and your description below this seems 
>>>> like a major change to try and use a facility (mach exceptions) 
>>>> that no one seems to have any experience with! That isn't something 
>>>> to be rushed.
>>>
>>>> Even if PT_ATTACH has been deprecated restoring its use may be the 
>>>> quick way forward instead of trying to rush in something like this.
>>>
>>> This approach looks reasonable to me.
>>
>> I've just realized that my statement might sound incorrectly.
>> I meant that the David's suggestion to restore the use of the 
>> deprecated PT_ATTACH looks reasonable.
>
> Forgot to send a link.
> Not sure, if an approach of replacing ptrace usage could be reasonable:
>   http://uninformed.org/index.cgi?v=4&a=3&p=14
>
>
> Thanks,
> Serguei
>
>
>>
>> Sorry, if it caused any confusion.
>>
>> Thanks,
>> Serguei
>>
>>
>>> Otherwise, it would be nice to hear why it is not good.
>>> How much would it break the fix of the JDK-8182299?
>>>
>>> Thanks,
>>> Serguei
>>>
>>>>
>>>> Just my 2c.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>> On 18/08/2017 8:00 PM, Jini George wrote:
>>>>> Hi all,
>>>>>
>>>>> Requesting reviews for: 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8184042
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/
>>>>>
>>>>> Problem gist: The deprecated ptrace() command, PT_ATTACH was 
>>>>> changed to PT_ATTACHEXC, which causes mach exceptions (and not 
>>>>> UNIX signals) to be delivered via mach messages.This caused SA to 
>>>>> hang at waitpid() waiting for a signal, which does not arrive.
>>>>>
>>>>> Solution in a nutshell: The solution is to make the required 
>>>>> changes to handle mach 'soft signal' exceptions in the form of 
>>>>> mach messages instead of signals, while attaching to and detaching 
>>>>> from the target process. The detailed steps are outlined in JBS.
>>>>>
>>>>> The changes appear huge due to the inclusion of pre-generated mach 
>>>>> exception handling files (mach_exc*). Since this is an integration 
>>>>> blocker, it would be great to get quick reviews on this.
>>>>>
>>>>> Thank you,
>>>>> Jini.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
>