October 2010 - Darwin-dev - lists.apple.com

Re: Breakpoint Implementation
by Dave Keck 08 Oct '10

08 Oct '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=8oG3pgResKB+XgPTEjW19xR1BTuZ2v7paERZGsRL99Y=; b=btZ4Lj4+ALpQZ8RIKooeMwINO6uyJTngFe67LeKwS1W70wC+dpn6MiVrIOzZPxtCZe hPLxJrLNfEt2mtignhG0Ue4p0mJhJxRgwxYnzaIdVV4Oo5YqGEJPO/+pGW4WfMVmhfT0 tv1XVENaGhPlSkOk3ow9RbU50z5X11oFobNG4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=RJqL9Poo9h63winSv49uUBs00CdNNqaGhK0VmvVWO4eXgd+nrFtLXKDeQ3TFAiaJF1 NVOvg6pbW7f3SulkT89cuvhxlltDM1HfcQdcz20IDO1I1gbmMXK4X/Ek/ZfNhlnWLOFG 5WSzdfGxrtuL1MmAznKED4l/4xKVQ5dMTqBGI= > Actually, the "run_state" member of the thread_basic_info_t structure returned for the thread_info() "flavor" argument of THREAD_BASIC_INFO returned in the "thread_info_out" data area argument will be TH_STATE_STOPPED. If you iterate over the task thread list, you can verify that this is the case for all threads. You really should be looking at the gdb source code for this type of information, since gdb has to solve similar problems. On my end, 'run_state' never contains a value of _STOPPED, only _WAITING; it returns _WAITING both when a thread is in a 'sleep(UINT_MAX)' call, and also when it's actually been suspended via thread_suspend(). (In addition to 'run_state,' none of the other members appear to report any useful information either regarding the "true suspension state.") Here's my test case: ========== #include <mach/mach.h> #include <pthread.h> #include <stdbool.h> #include <unistd.h> #include <stdio.h> void *func(void *a) { for (;;); } int main(int argc, const char *argv[]) { pthread_t p_thread = NULL; thread_act_t m_thread = MACH_PORT_NULL; pthread_create(&p_thread, NULL, func, NULL); m_thread = pthread_mach_thread_np(p_thread); usleep(500000); thread_suspend(m_thread); for (;; sleep(1)) { struct thread_basic_info m_thread_info; mach_msg_type_number_t m_thread_info_count = 0; m_thread_info_count = THREAD_BASIC_INFO_COUNT; thread_info(m_thread, THREAD_BASIC_INFO, (thread_info_t)&m_thread_info, &m_thread_info_count); printf("Run state: %d\n", m_thread_info.run_state); } return 0; } ========== Running this for several minutes never resulted in run_state == _STOPPED. I looked through the GDB sources but didn't find anything that uses thread_info() for a similar purpose as I'm attempting; I'll look again more thoroughly. Thanks, David _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Breakpoint Implementation
by Terry Lambert 08 Oct '10

08 Oct '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Oct 7, 2010, at 5:07 PM, Dave Keck wrote: >>> 1. Suspend every thread >> >> This procedure is not instantaneous. > > I see. Is there a technique to determine when a thread has actually > stopped executing? My testing shows that the information returned by > thread_info() cannot be used for this purpose. These are unsupported interfaces, and if you use them, you *will* break at some point in the future... Note that Apple generally does not document this type of information, since doing so would prevent changing the internal implementation details from release to release. Since we ship both the debugger and the OS, we can safely make such changes, but third parties can't rely on the implementation details not changing on a software update. So if this breaks your hobby project in a future release, you will need to recompile your code. - Actually, the "run_state" member of the thread_basic_info_t structure returned for the thread_info() "flavor" argument of THREAD_BASIC_INFO returned in the "thread_info_out" data area argument will be TH_STATE_STOPPED. If you iterate over the task thread list, you can verify that this is the case for all threads. You really should be looking at the gdb source code for this type of information, since gdb has to solve similar problems. Typically, this is done after a task_suspend(), which iterates over the threads in the task and sets suspend counts on all of them. Eventually they drain out of the scheduler run queues to an actually suspended state. It may be that you are looking at the thread state information before the threads have actually had a chance to get into the suspended state, or you could maybe be looking at the wrong information, since you can get several "flavors" of information back about threads, not just THREAD_BASIC_INFO. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Breakpoint Implementation
by Dave Keck 08 Oct '10

08 Oct '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=XbpEatdWS7Jpgao78xemUNH1Z57vbp5om3jCHb4Ivl4=; b=iFf1nBhHP8UWMbZjP6Zu7uRCXEUhetEgZNV7noydQELX/SmVF6Ve829JCQA5YyWMbB AhIbeZjmSiwWUNxHhDXIXtXwN1Np8t2a0F5DzWfXV9X/iclqxTyy8/pksXiAzy6a8rHU 9+PpQoR0MoPGzFEcR7Zl6ThVS9V3WHWPHiAEg= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=F6Gpp1gn+gi23gl71VqmeJ55k51JRxgGiBjdUcmL0RzC4C3TcxP5Hxk09WoIof393h qYvhjxcsgD+zQbRsQQgSd4Tes3Y7bIN4PXEI5srT+00AMETuJblfCYzszpIYMKxleYUT dvLzDteVcrerdcWVUYhxef64DEf8rpbexM7ZA= >> 1. Suspend every thread > > This procedure is not instantaneous. I see. Is there a technique to determine when a thread has actually stopped executing? My testing shows that the information returned by thread_info() cannot be used for this purpose. > (1) Security features will often prevent a page from being both writeable and executable, and may prevent a page from moving to executable if it has once been writable. The only exception to this would be operations in protected mode in the kernel to change these mappings (e.g. this is how dtrace emulates instructions when it replaces function preambles for FBT - Function Boundary Tracing). You can see this sort of thing in AntiVirus software or in copy protection, etc.. > > (2) Your code signature for the modified page will no longer be valid. If it gets checked after you modify it, depending on your signing flags, your program may be immediately killed. I can live with these problems for this hobby project. > (4) The syscall instruction is not a single byte; if it's tripped non-aligned, e.g. not on a 4 byte boundary, or crossing a cache line boundary, the update of an in progress instruction stream can be undefined. Because it's a single byte (0xCC), this is typically why people use INT3 for this type of thing in the first place, rather than trying to replace other instructions. Modifications are typically followed by a flush of the instruction cache, in case it's not write-back, since otherwise your changes may not be visible. This is typically why self-modifying code is strongly frowned upon these days. > > (5) Other threads in the same process can be running through the same code path at the same time, and if they happen to be on the same core as an SMT thread, depending on the cache and instruction scheduling microarchitecture, you could be running through the instruction stream being modified at the time of the modification, resulting in undefined behaviour (see #3, #4). I see – my (incorrect) assumptions regarding suspending every thread led me to believe I'd be safe here. >> 6. When Thread A hits the INT3 from step #4, set Thread A's EIP to the >> instruction after the cached EIP (from step #3) and resume > > You won't know why the INT3 got hit, and you won't be able to store per-thread state with the thread structure as a trigger indicator in any case. So for example, if someone is dtrace'ing at the same time (e.g. running "Instruments" as you are doing your thing, or your code is intended ), you are going to have a conflict. The way dtrace avoids this is that in the trap handler (by which I mean the protected mode kernel code used for handling hardware and software exceptions), it has a list of locations where it has placed its INT3's, and will look in the table to see if it sees one. If it doesn't, it will pass it through. However, there is nothing to prevent your code from mistaking a dtrace INT3 for one of its own, and there's nothing to prevent either of you from instrumenting over top of each other. This should also be acceptable for this project – I don't intend for it to be used simultaneously with other debugging utilities. Thanks Terry. As usual your help is much appreciated and beyond humbling. =) _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Breakpoint Implementation
by Terry Lambert 07 Oct '10

07 Oct '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Oct 7, 2010, at 12:58 AM, Dave Keck wrote: >> Alternately, you could use hardware breakpoints; see the gdb sources for details. > > I'll have to add support for those too. Looking at the GDB sources it > looks like it might be simpler than the INT3-replacement technique > too. > >> The typical way gdb deals with this is by being privileged due to code signing with regard to taskgated, such that taskgated permits it to do a task_for_pid() call on the process, get the task port, and handle the event as a Mach exception, rather than trying to handle it as a signal. This assumes it's either running under the same credential as the target process, or is running as a privileged used (e.g. via sudo). > > I should have mentioned that the breakpoint functionality is built on > Mach exceptions as you explain. It seems to work fine, but I must > admit that I'm confused by your mentioning of Dtrace and recompiling > the kernel to implement my own trap handler. Does that still apply > with breakpoints implemented using INT3-replacement and Mach > exceptions? Yes. INT3 causes software traps. That's how it works. Since dtrace uses INT3, if you use INT3, you will need to cooperate with dtrace or prohibit simultaneous execution. Since there's no way to enforce such an execution prohibition programmatically, you can either do it by administrative fiat ("documentation says 'don't do that'", trust people to read your documentation), or you can simply break when it happens. The only way to cooperate would be to hook where dtrace hooks, which is in the kernel trap handler, and since there's no way to do that programmatically either, you'd have to compile your own kernel to do it. Personally, I'd just use hardware breakpoints. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Breakpoint Implementation
by Terry Lambert 07 Oct '10

07 Oct '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Oct 7, 2010, at 12:59 AM, Dave Keck wrote: >> A harder solution is to leave the INT3 in place, and set EIP to an >> instruction buffer of your own on the side that says `syscall ; int3`. That >> way you can run a syscall instruction on that thread without interfering >> with any new thread. > > Clever - that sounds like the answer I was looking for. > >> (Of course, that new thread might stumble over one of >> your other breakpoints or mutate memory. If you want to handle that, you'd >> need a breakpoint on the first instruction for new threads, so you can catch >> the thread there and keep it halted until you're ready to resume threads.) > > Is that necessary? With this instruction buffer technique, when Thread > A hits Breakpoint A: > > 1. Suspend every thread This procedure is not instantaneous. You effectively set a suspend count and tell it to suspend itself when it's safe to do so. This does not occur in lock-step. The threads will continue to run for some time after this until they run up to a "safe" stopping point, at which point they will actually be suspended. This may include running code in the area you are attempting to modify. > 2. Let user handle breakpoint > 3. Cache Thread A's EIP > 4. Set EIP of Thread A to detached instruction buffer filled with > 'syscall; int 3' This is somewhat problematic: (1) Security features will often prevent a page from being both writeable and executable, and may prevent a page from moving to executable if it has once been writable. The only exception to this would be operations in protected mode in the kernel to change these mappings (e.g. this is how dtrace emulates instructions when it replaces function preambles for FBT - Function Boundary Tracing). You can see this sort of thing in AntiVirus software or in copy protection, etc.. (2) Your code signature for the modified page will no longer be valid. If it gets checked after you modify it, depending on your signing flags, your program may be immediately killed. (3) A fault in the detached instruction buffer in this case would be effectively unrecoverable. (4) The syscall instruction is not a single byte; if it's tripped non-aligned, e.g. not on a 4 byte boundary, or crossing a cache line boundary, the update of an in progress instruction stream can be undefined. Because it's a single byte (0xCC), this is typically why people use INT3 for this type of thing in the first place, rather than trying to replace other instructions. Modifications are typically followed by a flush of the instruction cache, in case it's not write-back, since otherwise your changes may not be visible. This is typically why self-modifying code is strongly frowned upon these days. (5) Other threads in the same process can be running through the same code path at the same time, and if they happen to be on the same core as an SMT thread, depending on the cache and instruction scheduling microarchitecture, you could be running through the instruction stream being modified at the time of the modification, resulting in undefined behaviour (see #3, #4). > 5. Resume every thread Also non-instantaneous. There will be a latency, potentially a substantial one, and the order in which the threads will be run afterward is indefinite. > 6. When Thread A hits the INT3 from step #4, set Thread A's EIP to the > instruction after the cached EIP (from step #3) and resume You won't know why the INT3 got hit, and you won't be able to store per-thread state with the thread structure as a trigger indicator in any case. So for example, if someone is dtrace'ing at the same time (e.g. running "Instruments" as you are doing your thing, or your code is intended ), you are going to have a conflict. The way dtrace avoids this is that in the trap handler (by which I mean the protected mode kernel code used for handling hardware and software exceptions), it has a list of locations where it has placed its INT3's, and will look in the table to see if it sees one. If it doesn't, it will pass it through. However, there is nothing to prevent your code from mistaking a dtrace INT3 for one of its own, and there's nothing to prevent either of you from instrumenting over top of each other. > Since Thread B won't be spawned until step #5 -- after the user has > handled the breakpoint and chosen to continue -- I don't see Thread > B's actions as being an issue. This is either an invalid assumption, or an assumption based on implementation details for your program which may not hold true for all programs. -- Terry > > Thanks, > > David > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-dev/tlambert%40apple.com > > This email sent to tlambert(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Breakpoint Implementation
by Dave Keck 07 Oct '10

07 Oct '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=af/dFHeyUIwRtNUOB9eRfFPnuoXar8EZO3tCxFHvH/Q=; b=suGh/loaa2iew0D7FAzliJgHj72Qqd750VY8W8LR3VnmIkMHaZHtA1PCvo1/+nmNnq XJs1lADdH8udl9wXC4poNpDIfL7yMdearKsR4ilb5TTGFECqyhcS8dmWWSyqPFTU40LE Yf8mkHY4dvpY5IV54UygZ7gT7YydDSzRTkgHs= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=d06jmY80hhkR8/uw+1LvwldRgvNfVpwWvddTqROPgPvcXZx+89ggmHswviFZ7EZkS2 jmlpKQmBW/MvpkeclyIPTIlqWrZWSow6MQ9bRN9BKqmXZriZM/jKOCkWzATOo+Bni0I1 /8Nx8Y2VUhK0dCxGhjSgF14tHea5gV18yNcEA= > A harder solution is to leave the INT3 in place, and set EIP to an > instruction buffer of your own on the side that says `syscall ; int3`. That > way you can run a syscall instruction on that thread without interfering > with any new thread. Clever - that sounds like the answer I was looking for. > (Of course, that new thread might stumble over one of > your other breakpoints or mutate memory. If you want to handle that, you'd > need a breakpoint on the first instruction for new threads, so you can catch > the thread there and keep it halted until you're ready to resume threads.) Is that necessary? With this instruction buffer technique, when Thread A hits Breakpoint A: 1. Suspend every thread 2. Let user handle breakpoint 3. Cache Thread A's EIP 4. Set EIP of Thread A to detached instruction buffer filled with 'syscall; int 3' 5. Resume every thread 6. When Thread A hits the INT3 from step #4, set Thread A's EIP to the instruction after the cached EIP (from step #3) and resume Since Thread B won't be spawned until step #5 -- after the user has handled the breakpoint and chosen to continue -- I don't see Thread B's actions as being an issue. Thanks, David _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Breakpoint Implementation
by Dave Keck 07 Oct '10

07 Oct '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=i+FycimjpFTuvBbPJuANKwzVUMmoBuGHQSUewPx0VvY=; b=Q1eUJpoeUuGi3EhKlsLzkhAGPHHr91nX9bgZ2nm5u2KvX3YBWgES5mzkBM4iXOT2TA 8Rbcoll2v84QC8LXrjE3tQZDe8a9CjK5xBUC0OpYZ3qYqm/F4sF1npKoupiUwoFBmJQX hpVZ9ihzEbyoQg2+bDgRlSlBDiZ9WEoYMN3I0= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=AXABs31nsYavYMb0Tpjgv6P3LkL+9LwyRLVD9vZ/KopOI8Max4/LkM4UMz+/0RFZsx umqls6GX7EoqIk6OnKhyQrKsyutcTSaD1FOFHLwNZHLqKneNk87A6fTAupLTKg6Qdhqd a6amvn/FjrsrVtlNUjpys7nkV0NHBkdSoSgng= > Alternately, you could use hardware breakpoints; see the gdb sources for details. I'll have to add support for those too. Looking at the GDB sources it looks like it might be simpler than the INT3-replacement technique too. > The typical way gdb deals with this is by being privileged due to code signing with regard to taskgated, such that taskgated permits it to do a task_for_pid() call on the process, get the task port, and handle the event as a Mach exception, rather than trying to handle it as a signal. This assumes it's either running under the same credential as the target process, or is running as a privileged used (e.g. via sudo). I should have mentioned that the breakpoint functionality is built on Mach exceptions as you explain. It seems to work fine, but I must admit that I'm confused by your mentioning of Dtrace and recompiling the kernel to implement my own trap handler. Does that still apply with breakpoints implemented using INT3-replacement and Mach exceptions? Thanks, David _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Power Management
by Andrew Gleave 06 Oct '10

06 Oct '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi. Can anyone tell me if there's any way of getting external power source amperage and voltage from the Power Management subsystem? Getting power change notifications and consumption data from a battery source via IOKit is straightforward, but I need to get the same type of data for instances when no battery is present (i.e. a desktop) or when a laptop is charging. IOKit will show when an AC / external power source is present, but I can't find a way of just getting the current being drawn from the charger / power cable. Can anyone shed any light on this? Thanks, Andrew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Breakpoint Implementation
by Greg Parker 06 Oct '10

06 Oct '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Breakpoint Implementation
by Terry Lambert 06 Oct '10

06 Oct '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Oct 4, 2010, at 1:20 AM, Dave Keck wrote: > Hey list, > > I'm implementing breakpoint functionality in a hobby i386 debugger > using the INT3 instruction. Let's say Thread 1 hits Breakpoint A: > > 1. Suspend every thread > 2. Restore original instruction that was replaced by INT3 > 3. In Thread 1, EIP--, let Thread 1 single-step (using EFL_TF flag) > 4. Revert instruction back to INT3 > 5. Resume every thread > > This technique appears to work as expected, but let's say: > > 1. Breakpoint A is at the very 'syscall' instruction within > pthread_create() that causes Thread B to spawn > 2. Thread B will hit Breakpoint A > > Due to the race between Thread B executing and step #4 completing, > couldn't Thread B bypass Breakpoint A? Is there a way to fix this? > > Thanks very much! > > David INT3 is problematic because it's used by dtrace. Since it's a single byte, rather than replacing an instruction and forcing emulation, which is what FBT does, SDT declares a label with a single byte NOP and replaces the NOP with the INT3. The issue you are going to see is that it's not going to be possible to wire into the trap handler for the INT3 trap, without compiling your own kernel to implement the trap handler. Alternately, you could use hardware breakpoints; see the gdb sources for details. If you pursue instruction replacement, your instruction emulation is going to have to understand that the breakpoint is on a particular thread, which is NOT thread B, and fix up any traps you get on thread B to be as if they had never happened. The typical way gdb deals with this is by being privileged due to code signing with regard to taskgated, such that taskgated permits it to do a task_for_pid() call on the process, get the task port, and handle the event as a Mach exception, rather than trying to handle it as a signal. This assumes it's either running under the same credential as the target process, or is running as a privileged used (e.g. via sudo). -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0