On Thu, 1 Oct 2026 00:47:06 GMT, Chris Plummer <[email protected]> wrote:
> On macOS 26.6.2 and 27, all the SA process tests are failing with a timeout. > I manually attached to a java process using clhsdb, and after the detach the > debuggee process was left suspended, so this seems to be the issue causing > the timeouts. Details in first comment. > > - Tested with all svc tier1 through tier8 testing on macosx-aarch64-debug. > - Ran all SA tests on various mach5 hosts 50 times each on macosx-aarch64 and > macosx-aarch64-debug. > - Tested on macOS 26.6.2 personal device by running serviceability/sa 120 > times on combination of debug and product builds > - Tested on macOS 27 mach5 devices by running serviceability/sa 100 times. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). The issue seems to be the timing and ordering of the SA detach code. Part of the issue seems to be that macOS is being slow to update the status of the debuggee, and sometimes SA does the detach steps too close together, leading to unexpected behavior during the detach. The result is the debuggee being left in a stopped state as if it had been stopped by a ctrl-Z. The first fix done, which resulted in about a 75% pass rate, was to move the mach_msg() call that replies to the exception so it is now earlier in the detach0() code before the PT_DETACH. Doing the reply before the PT_DETACH is the way it should always have been done. I guess we were just lucky to get away with it being after until 26.6.2 came along. A 2nd fix, which at one point seemed necessary but now I no longer believe is, is to call task_resume() during the detach since during the attach we did a task_suspend(). macOS often takes care of the resume during the PT_DETACH, but not always. Even when it doesn't do the detach, it seems to not cause any harm, but I kept this code in anyway since it keeps things symmetrical with the attach code and is the "right" thing to do. A 3rd fix, which was removed, was to put a short delay in between restoring the exception ports and doing the detach. This got an almost 100% pass rate, but in the end was not enough. The 4th fix below was needed, and once in place, the delay was not. The 4th fix is to deal with a macOS timing/latency issue where at some point after the PT_DETACH macOS suddenly changes the status of the target process from SRUN to SSTOP. When this happens the target process is left in the suspended state, which results in the timeouts we were seeing. My assumption is that this is the result of delayed or spurious application of the SIGSTOP that was generated during the attach, but I'm not certain. What I do know is issuing a SIGCONT when the status is SSTOP does get the target process unsuspended, and finally 100% of tests passing. One other note is that a short delay (sleep) is needed before checking the process status for SSTOP because if done right way the status is almost always still SSRUN. We need to delay to give the process a chance to get to the SSTOP state. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33158#issuecomment-5922436372
