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.spit...@oracle.com wrote:
On 9/7/17 14:39, serguei.spit...@oracle.com wrote:
On 8/25/17 02:24, serguei.spit...@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.
