This is the mail archive of the
mailing list for the systemtap project.
Re: print_backtrace not printing full stack
Jim Keniston wrote:
On Thu, 2006-08-10 at 14:35, Mike Mason wrote:
Hmm... I didn't think about the user portion of the stack being missing.
Perhaps open() isn't a good example. I tried probing the entry to open()
and printing the backtrace. Saw the same results.
You're probing sys_open(), which is dispatched directly from the system
call table, at least on some architectures. On i386, I'd expect to see
an entry for sys_open and one for the code that called sys_open
(sysenter_past_esp in entry.S), but that's all. sysenter_past_esp is a
label in what is essentially the entry point into the kernel for system
Which architecture are you testing?
x86_64. I just tried the same script on i386 and print_backtrace() works as
expected. The problem appears to be x86-64 specific. I'll file a bug.
Then I tried a few
other probe points, including schedule() in sched.c.
No matter where I
probe, I only get one line of the stack.
That sounds like a bug. Is that one line in the probed function, in its
caller, or what? (I'm assuming you don't see the kretprobe_trampoline
line if it's not a kretprobe.)
It depends. If I probe sys_open(), I see sys_open() only. If I probe
schedule() in sched.c, I see a line for __sched_text_start and that's all.
You're right, I only see kretprobe_trampoline for return probes.
BTW, on powerpc, at least, print_backtrace() reports the bulk of the
stack trace as one long line, apparently no matter how many functions
are reported. Are you seeing just one function reported, or multiple
functions on one line?
On powerpc, I'm seeing as you describe. All the functions appear to be
printed, but most are on one long line.