> But there's still a difference, right? And when called or passed through alot,
> that small difference can become really big.
...
> The fwrite was just an example. We actually do our debugging through memory
> first (ofcourse, there's still locking) and then another debugger thread does
> the wri
> 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
> calling CrashLogThreadID(pthread_t) might be too costly for every
> call to my custom debugLog(...)
I've done it that way when debugging threads. It doesn't take long; none of
the calls take very long, especially when compared to what goes on when
writing to a log anyway.
Do note though that wr
On Dec 17, 2008, at 10:11 PM, Greg Parker wrote:
Of course, if the number of threads changes then that cached thread
ID may not match the crash log anymore. (And the number of threads
in your process may change due to code outside your control.)
Ah, right. Never mind. :)
-Dave
___
On Dec 17, 2008, at 8:03 PM, Dave Dribin wrote:
On Dec 17, 2008, at 7:37 PM, radj wrote:
I see. I'm not trying to be ungrateful (because I really am, thanks
for the
code), but calling CrashLogThreadID(pthread_t) might be too costly
for every
call to my custom debugLog(...) because there are a
On Dec 17, 2008, at 7:37 PM, radj wrote:
I see. I'm not trying to be ungrateful (because I really am, thanks
for the
code), but calling 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,
> The crash log's thread ID is not fixed. If you run ten helper threads and
> nine of them exit before you crash, the surviving helper thread will always
> be "Thread 1" in the crash log. Any scheme that tries to predict the crash
> log's thread ID will be unreliable - a thread could always be crea
On Dec 17, 2008, at 4:22 PM, radj wrote:
Yes, looking at the stack trace can help me identify which is which
but what
if the threads all look the same? ex: I've launched several threads
of the
same method. But that's another question.
What I needed is:
I have my own debug log, my program wri
>
> Check out CrashReporter Technical Note TN2123 (google "TN2123") - the
> advice there (~p.8) is to look at the symbolic names within the backtrace in
> order to identify which thread is which.
Woops. Looks like I wasn't stating what I needed clearly.
Yes, looking at the stack trace can help
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,
Radj
Hi Radj,
Check out Crash
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,
Radj
___
11 matches
Mail list logo
