On 14/02/2013 10:44 PM, Staffan Larsen wrote:
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.
Looks okay to me.
Thanks,
David
Thanks,
/Staffan
On 14 feb 2013, at 13:04, Staffan Larsen <staffan.lar...@oracle.com> wrote:
On 14 feb 2013, at 11:40, David Holmes <david.hol...@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
