Re: Custom data formatter for pthread_mutex_t?
Re: Custom data formatter for pthread_mutex_t?
- Subject: Re: Custom data formatter for pthread_mutex_t?
- From: Cem Karan <email@hidden>
- Date: Mon, 20 Aug 2007 11:30:50 -0400
OK, that was what I thought you might be doing. The problem with
this is the race condition that Kyle mentioned, and that I've been
trying to avoid myself; because the threads are 100% independent of
one another (except for mutex regions), the time you spend writing
through to your scratch pad changes the timing between the threads.
This may not seem like much, but on a multi-processor machine that
can be enough to ensure that your code always runs one way in your
debug code, but differently in your release code. That was why I was
so interested in seeing if you'd found a truly 0 overhead way of
probing the state of the locks.
As it stands, I have used a similar method to write when I locked a
lock, and when I released it (all wrapped in macros). I found that
the running behavior between the debug version and the release
version never quite matched. By using long running statistical
testing (fuzzing) in my unit tests, I managed to get enough
information that I squashed most (all?) of my bugs, but what I really
want is a way of probing the state of locks in a way guaranteed to
not modify the running behavior of the threads. The only way for
that to happen is for GDB to pause all threads at the same time, and
then to probe the locks individually, which, when you really get down
and dirty, is impossible.
I guess I'm going to have to go with my original hack method from way
back when; macros wrapping the pthread calls which dump their state
to a log, and then use lots of statistical testing to see if what is
happening is what I expect.
Thanks,
Cem Karan
On Aug 20, 2007, at 10:52 AM, alex wrote:
Okay, let me explain a bit better:
Each "lock" has 8 bits that is statically allocated to the lock at
"compile time". Therefore every lock I create has a little
"scratch pad" associated with it. This scratch pad is actually
just a big memory block that I have partitioned for each lock that
is created.
I wrap every pthread API with my own routine that calls straight
thru to the pthread API and after that simply writes the return
value of that API call into the scratch area for that lock. I used
a macro to write to the scratch data so that part can be disabled
in release code.
Finally the way you use this is you write a function to walk thru
your scratch pad and return all the lock states- This function can
only be called when the program is stopped. This takes advantage
of the fact that GDB allows you to call functions directly:
(gdb) call (void)DebugPrintLockStates()
$1 = { lock states listed here }
Hope this helps,
alex
At 8:14 AM -0400 8/20/07, Karan, Cem (Civ, ARL/CISD) wrote:
Apologies about coming in late, I've been out for 3 days.
Alex, I'm not sure I understand what you are doing; how are you
ensuring
that the code is only called when your process is stopped? Do you
mean
that your code is writing the state of the lock right before it
calls a
pthread_cond_wait(), and that your threads are not affected by this
extra code, or do you mean that you've gotten GDB/Xcode to execute
code
only when you hit a breakpoint? If you've got some nifty way of
making
the latter happen such that there is 0 overhead while the code is
normally running, I'd love to hear it! I know that if I can
sample the
state of a lock after I've hit a breakpoint, then life is good.
Hmmm.... OK, I have no experience with custom data formatters, so
please
forgive my ignorance. Is it possible to write a custom formatter
that
can call pthread_mutex_trylock()from within XCode/GDB's context on a
lock in the application's context? If so, then I can let my code run
until it hits a breakpoint, know that the code is stopped, and use
trylock() to test the state of the lock. This would also negate the
need for custom macros and all the other usual tricks, and it
would be
portable to any pthreads code that needs to be debugged (the data
formatter can be with Xcode, not the project code)
_______________________________________________
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