Bug 5085 - print_backtrace() and backtrace() not working in timer.profile probe on 2.6.23-rc8 kernel
Summary: print_backtrace() and backtrace() not working in timer.profile probe on 2.6....
Status: RESOLVED DUPLICATE of bug 5635
Alias: None
Product: systemtap
Classification: Unclassified
Component: testsuite (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-02 14:22 UTC by William Cohen
Modified: 2008-11-06 03:27 UTC (History)
0 users

See Also:
Host: i686
Target:
Build:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description William Cohen 2007-10-02 14:22:36 UTC 
With the 2.6.23-rc8 kernel the following tests fail:

FAIL: backtrace of timer.profile (1)
FAIL: print_stack of timer.profile (0)

This is from testsuite/systemtap.context/backtrace.stp. Looking through the
systemtap.log see bogus addresses like the following:

--------

backtrace from timer.profile:

 0x001d3392

--------

the profile stack is 0x001d3392

--------

 0x001d3392

--------

Note that the test is passing on the same machine with the standard RHEL4
kernel,  2.6.9-55.0.9.ELsmp
Comment 1 Masami Hiramatsu 2007-10-02 15:19:28 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.
Comment 2 Josh Stone 2007-10-02 15:20:12 UTC 
Why do you say that is bogus?  Those look like a userspace address, which is
reasonable for timer.profile...
Comment 3 William Cohen 2007-10-02 15:40:58 UTC 
"bogus" is a poor choice of words. the test should be more forgiving of
userspace values.
Comment 4 Masami Hiramatsu 2007-10-02 15:57:20 UTC 
In user space, probefunc() returns "". So, the test can skip if the profile
probe is in user mode.
Comment 5 Martin Hunt 2007-10-02 18:20:07 UTC 
(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.
Comment 6 Masami Hiramatsu 2007-10-03 19:54:06 UTC 
(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().
Comment 7 Masami Hiramatsu 2007-10-23 18:28:32 UTC 
(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.
Comment 8 Frank Ch. Eigler 2008-11-06 03:27:10 UTC 
User-space backtracing should work.


*** This bug has been marked as a duplicate of 5635 ***