RFR(S): 8008102: SA on OS X does not stop the attached process
Staffan Larsen
staffan.larsen at oracle.com
Thu Feb 14 04:44:51 PST 2013
Here is an updated webrev: http://cr.openjdk.java.net/~sla/8008102/webrev.01/
This uses the code from linux (adapted to the OS X API:s) to call ptrace and make sure we are stopped by the right signal.
Thanks,
/Staffan
On 14 feb 2013, at 13:04, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>
> On 14 feb 2013, at 11:40, David Holmes <David.Holmes at oracle.com> wrote:
>
>> On 14/02/2013 1:05 AM, Staffan Larsen wrote:
>>> Please review the following change.
>>>
>>> When SA attaches to a JVM on OS X, it does not stop the process. If the JVM keeps running while SA inspects it can lead to all kinds of inconsistencies in SA. The proposed solution uses ptrace to attach to the process to keep it from running. Ptrace works a little bit differently on OS X, than on linux. For example, there is no need to attach to all threads, just attaching to the main process is enough. Additionally, the race that was recently found on linux [1] does not seem to be present on OS X (or at least I have not been able to reproduce it), so I have omitted that code.
>>
>> I would question how you can know for certain that the signal race [1] can not happen on OSX? Would it not be prudent (and lend itself to future code sharing) to follow the same approach as now used on Linux?
>
> I did not say I was certain, merely that I have not been able to reproduce it. I think there are big differences in how ptrace is implemented on Linux and OS X that explains why I don't see the same race. Anyway, you are right that we should be prudent and employ the same technique on OS X. New webrev coming.
>
>> I kind of dismayed that the OSX SA support has been found to be in such poor shape. Makes me wonder what else in that port is lacking robustness.
>
> So do I...
>
> /Staffan
>
>>
>> David
>>
>>> webrev: http://cr.openjdk.java.net/~sla/8008102/webrev.00/
>>>
>>> Thanks,
>>> /Staffan
>>>
>>> [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-February/008432.html
>>>
>
More information about the serviceability-dev
mailing list