| Summary: | print_backtrace() and backtrace() not working in timer.profile probe on 2.6.23-rc8 kernel | ||
|---|---|---|---|
| Product: | systemtap | Reporter: | William Cohen <wcohen> |
| Component: | testsuite | Assignee: | Unassigned <systemtap> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Host: | i686 | Target: | |
| Build: | Last reconfirmed: | ||
|
Description
William Cohen
2007-10-02 14:22:36 UTC
(In reply to comment #0) > backtrace from timer.profile: > > 0x001d3392 > > -------- > > the profile stack is 0x001d3392 > > -------- > > 0x001d3392 > It was reproduced on my machine with 2.6.22.9-91.fc7. timer.profile will be invoked when a user program is running, and backtracing fails on user stack. I think we need to introduce a function to check whether the probe is in the kernel or in user mode. Why do you say that is bogus? Those look like a userspace address, which is reasonable for timer.profile... "bogus" is a poor choice of words. the test should be more forgiving of userspace values. In user space, probefunc() returns "". So, the test can skip if the profile probe is in user mode. (In reply to comment #3) > "bogus" is a poor choice of words. the test should be more forgiving of > userspace values. I thought I fixed this last week. Do you have this in testsuite/ChangeLog? 2007-09-25 Martin Hunt <hunt@redhat.com> * systemtap.context/backtrace.tcl: Handle single line timer.profile backtraces. (In reply to comment #5) > I thought I fixed this last week. Do you have this in testsuite/ChangeLog? > 2007-09-25 Martin Hunt <hunt@redhat.com> > > * systemtap.context/backtrace.tcl: Handle single line timer.profile > backtraces. Thanks to fix that, however, I think that is not related to this issue. (In my case, I used the latest cvs source code.) it is hard to get the function name from userspace without debuginfo of the application. So, I recommend to skip the timer.profile handler in the test if it is invoked in userspace. I think we can check that by using probefunc(). (In reply to comment #6) > it is hard to get the function name from userspace without debuginfo of the > application. So, I recommend to skip the timer.profile handler in the test if it > is invoked in userspace. I think we can check that by using probefunc(). I think we can check it by introducing new user_mode() function which just invokes user_mode() macro. |