JDK-8189429 : SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2017-10-17
  • Updated: 2018-10-18
  • Resolved: 2018-06-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12
11 b20Fixed 12Fixed
Related Reports
Duplicate :  
JDK-8186427 - SA: MacOSX: Include the generation of the mach_exc* files with the mig command as part of the build.
Relates :  
JDK-8152899 - Xcode 7.3 problems
Relates :  
JDK-8184042 - several serviceability/sa tests timed out on MacOS X
Description
The argument PT_ATTACH for ptrace() attaching to a target process is deprecated and has to be replaced by PT_ATTACHEXC. This causes signals (SIGSTOP during attach) from the debuggee to be delivered as Mach exceptions. Modifications would need to be done within SA to handle these. The webrev for the change is at: http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/ and the mails wrt this are at: http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021702.html
Comments
The solution proposed in SA is along the lines of how exceptions due to PT_ATTACHEXC get handled in other debuggers like gdb and lldb. Since the SIGSTOP signal is delivered in the form of a Mach exception message, the proposed solution is to avoid the waitpid() and have modifications done in SA to receive, handle and reply to the incoming Mach exception message. When an exception occurs, the faulting thread (in our case, the debuggee) is suspended by the kernel and a message containing the information about the exception such as the exception type, the thread that caused it, and the thread's containing task gets sent to a registered exception port by the kernel for that exception. The reply to this message, which the faulting thread waits for, indicates whether the exception was successfully handled by an exception handler (in our case, this would be SA). The faulting thread remains suspended in the kernel until a reply is obtained from the exception handling thread. The high level steps for attaching to a target process are somewhat as follows: * Allocate an exception port for receiving exception messages on behalf of the target process. * Add the ability to send messages on this exception port. * Save the list of exception ports of the target process (so that we restore it later while detaching from the process). * Register the newly allocated exception port with the target process. * Invoke ptrace with PT_ATTACHEXC on the target process. * Wait for the exception message from the kernel with the mach_msg() call by listening in on the newly created exception port. * Once the reply is obtained, call mach_exc_server() to parse and decode the kernel exception message, and to prepare a reply which would need to be sent by SA to the target process while detaching. Else the target would continue to remain suspended in the kernel. * mach_exc_server() resides in code generated by running the mig(1) command. The generation of this code is included in the build. mach_exc_server() invokes the catch_mach_exception_raise() routine which has to be implemented in SA. * Implement the catch_mach_exception_raise() routine to check that the message denotes a Unix soft signal, and return a "KERN_SUCCESS" (which would cause the generated mach_exc_server() routine to create a reply message indicating that this exception is being handled). * Suspend all the threads in the target task with task_suspend(). The steps to be followed while detaching: * Restore the pre-saved original exception ports registered with the target process. * Invoke ptrace() with the "PT_DETACH" request on the target process. * Reply to the previous "mach soft signal" exception, since unless this acknowledgement is sent, the thread raising the exception (in the target) remains suspended. The reply message to be sent is obtained from the previous call to mach_exc_server(). * Release the exception port allocated while attaching to the target using mach_port_deallocate().
22-06-2018