This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Thursday, October 19, 2006 1:47 PM, David Boreham wrote:Yeah, that was the kind of hack I was thinking of.
I'd like to get a stack trace for the process that made the system call I'm probing (I'm looking at filesystem access typically, so reads/writes/syncs etc). The systemtap backtrace function appears to only get the kernel mode stack which is not much use to me. I was wondering if anyone had discovered a good solution to this problem already ? I was thinking perhaps I could invoke pstack (gdb) on the current pid/tid. But I'm worried that doing so might deadlock since the process is inside a system call.
I'm looking at a very large application that beats up on the filesystem, in case you're wondering why I want to do this. It's so large that nobody is quite sure what code access which files, when and why.
Thanks.
Deadlock issues aside, there's not really a way for you to invoke a
process (like pstack) from within a SystemTap script. You could run a
separate user program or script to do this for you though, and then you
just need to coordinate with SystemTap. Such a method might look like
this:
Of course at the end of the day, this is just a convoluted strace with aNot really. The application that I'm battling with is resistent to my 'traditional'
stack printout.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |