> I've done it that way when debugging threads. It doesn't take long; none of
> the calls take very long,
But there's still a difference, right? And when called or passed through
alot, that small difference can become really big.
> especially when compared to what goes on when
> writing to a log
ng CrashLogThreadID(pthread_t) might be too costly for every
call to my custom debugLog(...) because there are alot all over the code
(not the best practice, me thinks). But thanks to your intro to
task_threads(), I can follow the idea and try my own array of
ead's number from within my code that will match with crash log's
thread numbers? :D
ex:
fwrite(filePointer, "[thread:%d] a trivial sample debug log line showing the
thread number\n", ____ ); // what should go in the blank?
Cheers,
radj
_
Hello List,
I've been googling and searching for this but to no joy. How do you get a
thread ID of the current thread that will be similar with the one that shows
up on a crash log? This is pretty helpful for debugging multi-threaded
applications.
Thanks,
m the driver but unfortunately, dtrace
requires more previliges than "_lp" user can give. And I've read that
authentication is a little complicated. I bet I can find lots of examples of
running stuff as root in other threads.
Thanks for all your help, guys!
radj
he application does not run as "root" but as "_lp". Is that a big factor in
the error?
Cheers,
radj
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contac
I tried the raise() in D script. My driver got the signal but it kinda
malfunctioned, it got stuck somehow although it still can accept any signal.
Weird. My small experience can't tell me anything.
So I googled up some more D trace commands and found system(). I tried this
instead:
pid$1::dummyC
>
> I'm not sure I understand what you're asking. Are you looking for the
> dtrace:::BEGIN probe? If you put an action on that, it's executed when
> DTrace starts tracing.
>
This is exactly what I'm looking for. Thanks again! :)
___
Cocoa-dev mailing
t possible to
use raise() when dtrace command has finished compiling and not when a probe
fires?
Curious,
radj
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact
t possible to
use raise() when dtrace command has finished compiling and not when an objc
probe fires?
radj
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators a
Finally got it to poll. I had to study signals and signal handling within
the driver. lol. I've tried it and atleast it helps me delay the actual
"initialization" of the driver while I run the D script.
Your quick responses were really helpful. Thanks alot, Bill!
DTrace rocks!
ra
> Personally, I would start by trying to use a signal handler. See
> x-man-page://signal (the signal man page). Specifically, I would write a
> handler for SIGUSR1 or SIGUSR2 as those exist explicitly to offer user
> specific behaviors. Take a command line option or read an environment
> varia
12 matches
Mail list logo
