On 2010 Jun 13, at 12:34, Dave Keck wrote:
>> What might cause this process to exit? Where can I look for clues? (I've
>> been guessing for two hours, so any suggestion will be welcome.) Does the
>> system log the exit states of processes anywhere?
>
> I would attach to the process while it's executing (in Xcode, Run >
> Attach to Process) and set a breakpoint on exit()/_exit() to get a
> backtrace when it exits.
Thanks, Dave. That gave me the clue I needed.
Although no break occurred on either symbol 'exit' nor '_exit', gdb noted that
"Program received signal SIGTERM". So I ran a little DTrace probe [1] process
to see who was sending SIGTERM, and the answer was that it was sending SIGTERM
to itself, which didn't make any sense, but got me to thinking and then I
discovered the real problem which was that the app which was running the
AppleScript concludes with a wholesale unloading, rewriting and reloading of
all its launchd configurations, including the one which had launched the tool.
And according to man launchctl, unloading a configuration kills any of its
processes which happen to be still running.
Oh well, not be a Cocoa problem. Need to be more selective in my launchd
housekeeping.
[1]
#!/usr/sbin/dtrace -qs
proc:::signal-send
/args[2] == SIGTERM/
{
printf("SIGTERM was sent by %s pid=%d \n", \
args[1]->pr_fname,args[1]->pr_pid);
}
# This script was adapted from
http://www.sun.com/bigadmin/features/articles/dtrace_truss.jsp
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
