0

OK, this is "fun." I'm trying to figure out a weird thread timeout in a program, and need to look at what is happening when pthread_cond_timedwait() returns on Solaris... But... Only when a certain wrapper function or functions are being called (call them foo_lock and foo_unlock)...

I don't think I can use this answer because the function I'm looking at is at least 2-3 hops up in the stack: dtrace execute action only when the function returns to a specific module

One of the weird behaviors is that I see the right parent in tracing entry, but not exit, when I use a return probe... This could be a buffering issue though. Have to dig...

Mateusz Piotrowski
  • 8,029
  • 10
  • 53
  • 79
Brian Cowan
  • 1,048
  • 6
  • 7
  • Try creating a thread-local variables (like `tracing_foo_lock` and `tracing_foo_unlock` that you set to `1` on `entry` probe then `0` on `return` probes. Then you can write two probes for `pthread_cond_timedwait()` that use those `tracing_*` thread-local vars as predicates. – danielbeard Jan 19 '22 at 22:25
  • I wound up instrumenting the program itself, because it turns out that the conditional is stored in an array inside of a memory mapped shared memory area, between multiple applications... Said memory mapped area is pointed to by a global variable and essentially invisible to dtrace without some weird changes.. It was simpler to go upstream to where the index in the array is exposed... Of course, in the process I found that the routine in one app that's supposed to wake the other doesn't seem to be called @ all. Wheee. Time to go spelunking... – Brian Cowan Jan 28 '22 at 22:24

0 Answers0