Re: debug a forked PTY process
Re: debug a forked PTY process
- Subject: Re: debug a forked PTY process
- From: Ken Thomases <email@hidden>
- Date: Tue, 9 Mar 2010 17:05:41 -0600
On Mar 9, 2010, at 5:25 AM, James Larcombe wrote:
>> The process has forked and you cannot use this CoreFoundation
>> functionality safely. You MUST exec(). Break on
>> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_
>> THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
>
> I have a related question regarding this message.
>
> As far as I can tell, you can't actually set a breakpoint on that
> function, because it's a private symbol, as you can see in the source:
>
> http://www.opensource.apple.com/source/CF/CF-550.13/CFRuntime.c
>
> What's the best recommendation here? I had a curious instance of that
> warning recently but couldn't see why it was arising as we weren't
> forking anywhere that I could see. DTrace is difficult to use in this
> case because attaching to the process won't follow the forked process
> when it is created.
>
> Any debugging suggestions?
You can use DTrace like so:
sudo dtrace -n 'syscall::write*:entry /execname=="yourprogramnamehere" && arg0==2/ {ustack();}'
That is a wider net than you'd ideally want. It captures all writes to stderr. But you probably shouldn't have so many of those that they drown out the one you're looking for.
You could copy the buffer argument in and print its contents to help you identify the occurrence, if necessary. This may have to be done on the "return" probe instead of the "entry" probe, because the buffer data may not be in memory at entry time. (That's a common DTrace idiom. If you're not familiar with it, you'll have to read some DTrace guides. I forget where I learned it.)
Cheers,
Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden