* Why dump_stack results different so much?
@ 2005-07-29 20:27 Xin Zhao
2005-07-29 20:34 ` bert hubert
0 siblings, 1 reply; 6+ messages in thread
From: Xin Zhao @ 2005-07-29 20:27 UTC (permalink / raw)
To: linux-kernel
I tried to use dump_stack to dump the calling trace in the kernel.
What I did is adding a dump_stack() call in the sys_open function.
Below is the dump out result:
Jul 28 17:33:31 normal kernel: [<c0151601>] sys_open+0xa6/0xb7
Jul 28 17:33:31 normal kernel: [<c0108e2c>] syscall_call+0x7/0xb
However, if I insert a new kernel module which does nothing but
pointing the orignal sys_open to our_sys_open(), and in
our_system_open(), I simply do return sys_open();
I supprisely noticed that the dump_stack results are quite different!
Why did I get the calling traces below our_ssy_open() and above
syscall_call()? Any thought on this? Many thanks!
Jul 28 17:33:42 normal kernel: [<c0151601>] sys_open+0xa6/0xb7
Jul 28 17:33:42 normal kernel: [<d080f02c>] our_sys_open+0x2c/0x33 [trace]
Jul 28 17:33:42 normal kernel: [<c0114984>] __wake_up+0x41/0x81
Jul 28 17:33:42 normal kernel: [<c02c5e44>] sbf_read+0x5a/0x6f
Jul 28 17:33:42 normal kernel: [<c01c4e12>] journal_stop+0x159/0x279
Jul 28 17:33:42 normal kernel: [<c01b7aff>] ext3_mark_iloc_dirty+0x25/0x2f
Jul 28 17:33:42 normal kernel: [<c02c5e44>] sbf_read+0x5a/0x6f
Jul 28 17:33:42 normal kernel: [<c01b7bef>] ext3_mark_inode_dirty+0x3d/0x44
Jul 28 17:33:42 normal kernel: [<c02c5e44>] sbf_read+0x5a/0x6f
Jul 28 17:33:42 normal kernel: [<c01c583a>] __journal_file_buffer+0xbb/0x282
Jul 28 17:33:42 normal kernel: [<c01546ed>] bh_lru_install+0xc3/0xdf
Jul 28 17:33:42 normal kernel: [<c01c4169>] do_get_write_access+0x36f/0x5ea
Jul 28 17:33:42 normal kernel: [<c01c583a>] __journal_file_buffer+0xbb/0x282
Jul 28 17:33:42 normal kernel: [<c01c4a39>] journal_dirty_metadata+0xf4/0x16d
Jul 28 17:33:42 normal kernel: [<c0114984>] __wake_up+0x41/0x81
Jul 28 17:33:42 normal kernel: [<c01c4e12>] journal_stop+0x159/0x279
Jul 28 17:33:42 normal kernel: [<c01b7aff>] ext3_mark_iloc_dirty+0x25/0x2f
Jul 28 17:33:42 normal kernel: [<c01b7bef>] ext3_mark_inode_dirty+0x3d/0x44
Jul 28 17:33:42 normal kernel: [<c01bc111>] __ext3_journal_stop+0x1e/0x44
Jul 28 17:33:42 normal kernel: [<c01b7c5c>] ext3_dirty_inode+0x66/0x7b
Jul 28 17:33:42 normal kernel: [<c01736fc>] __mark_inode_dirty+0xec/0x1ce
Jul 28 17:33:42 normal kernel: [<c011cbd4>] current_fs_time+0x4d/0x5b
Jul 28 17:33:42 normal kernel: [<c0107606>] __switch_to+0x2a/0x365
Jul 28 17:33:42 normal kernel: [<c0107606>] __switch_to+0x2a/0x365
Jul 28 17:33:42 normal kernel: [<c0132c3d>] find_get_page+0x30/0x6a
Jul 28 17:33:42 normal kernel: [<c015f35b>] do_lookup+0x24/0x89
Jul 28 17:33:42 normal kernel: [<c01686fc>] dput+0x95/0x252
Jul 28 17:33:42 normal kernel: [<c015ff9d>] link_path_walk+0xbdd/0xe86
Jul 28 17:33:42 normal kernel: [<c0121778>] free_uid+0x1c/0x6d
Jul 28 17:33:42 normal kernel: [<c01e63de>] copy_to_user+0x3c/0x4a
Jul 28 17:33:42 normal kernel: [<c015b519>] cp_new_stat64+0xf5/0x105
Jul 28 17:33:42 normal kernel: [<c015b55a>] sys_stat64+0x31/0x36
Jul 28 17:33:42 normal kernel: [<c0108e2c>] syscall_call+0x7/0xb
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why dump_stack results different so much?
2005-07-29 20:27 Why dump_stack results different so much? Xin Zhao
@ 2005-07-29 20:34 ` bert hubert
2005-07-29 21:00 ` Xin Zhao
0 siblings, 1 reply; 6+ messages in thread
From: bert hubert @ 2005-07-29 20:34 UTC (permalink / raw)
To: Xin Zhao; +Cc: linux-kernel
On Fri, Jul 29, 2005 at 04:27:16PM -0400, Xin Zhao wrote:
> I supprisely noticed that the dump_stack results are quite different!
> Why did I get the calling traces below our_ssy_open() and above
> syscall_call()? Any thought on this? Many thanks!
This might depend on compiling with frame pointers, or not. I recall that at
one point, the kernel did a basic scan of addresses that looked like likely
candidates to have been pointers, and printed those.
Frame pointers are hailed as improving backtraces. They are in the 'kernel
hacking' section of the kernel configuration.
Sorry that I can't be more precise, but try turning on frame pointers.
Good luck!
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why dump_stack results different so much?
2005-07-29 20:34 ` bert hubert
@ 2005-07-29 21:00 ` Xin Zhao
2005-07-29 21:22 ` bert hubert
0 siblings, 1 reply; 6+ messages in thread
From: Xin Zhao @ 2005-07-29 21:00 UTC (permalink / raw)
To: bert hubert, Xin Zhao, linux-kernel
Thanks for your reply.
Below is the code that print the kernel calling trace:
/**********************************************************************************/
void show_trace(struct task_struct *task, unsigned long * stack)
{
unsigned long ebp;
if (!task)
task = current;
if (task == current) {
/* Grab ebp right from our regs */
asm ("movl %%ebp, %0" : "=r" (ebp) : );
} else {
/* ebp is the last reg pushed by switch_to */
ebp = *(unsigned long *) task->thread.esp;
}
while (1) {
struct thread_info *context;
context = (struct thread_info *)
((unsigned long)stack & (~(THREAD_SIZE - 1)));
ebp = print_context_stack(context, stack, ebp);
stack = (unsigned long*)context->previous_esp;
if (!stack)
break;
printk(" =======================\n");
}
}
/**********************************************************************************/
>From this code, I can see that the show_trace does not scan and guess
the pointers. Instead, it use "previous_esp" to extract the esp and
thus the returning eip. Am I right?
Cheers,
xin
On 7/29/05, bert hubert <bert.hubert@netherlabs.nl> wrote:
> On Fri, Jul 29, 2005 at 04:27:16PM -0400, Xin Zhao wrote:
> > I supprisely noticed that the dump_stack results are quite different!
> > Why did I get the calling traces below our_ssy_open() and above
> > syscall_call()? Any thought on this? Many thanks!
>
> This might depend on compiling with frame pointers, or not. I recall that at
> one point, the kernel did a basic scan of addresses that looked like likely
> candidates to have been pointers, and printed those.
>
> Frame pointers are hailed as improving backtraces. They are in the 'kernel
> hacking' section of the kernel configuration.
>
> Sorry that I can't be more precise, but try turning on frame pointers.
>
> Good luck!
>
> --
> http://www.PowerDNS.com Open source, database driven DNS Software
> http://netherlabs.nl Open and Closed source services
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why dump_stack results different so much?
2005-07-29 21:00 ` Xin Zhao
@ 2005-07-29 21:22 ` bert hubert
2005-07-30 0:10 ` Xin Zhao
0 siblings, 1 reply; 6+ messages in thread
From: bert hubert @ 2005-07-29 21:22 UTC (permalink / raw)
To: Xin Zhao; +Cc: linux-kernel
On Fri, Jul 29, 2005 at 05:00:20PM -0400, Xin Zhao wrote:
> Thanks for your reply.
>
> Below is the code that print the kernel calling trace:
Can I suggest just turning on frame pointers like I suggested?
If you say Y here the resulting kernel image will be slightly larger
and slower, but it will give very useful debugging information.
If you don't debug the kernel, you can say N, but we may not be able
to solve problems without frame pointers.
Good luck!
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why dump_stack results different so much?
2005-07-29 21:22 ` bert hubert
@ 2005-07-30 0:10 ` Xin Zhao
2005-07-30 11:52 ` bert hubert
0 siblings, 1 reply; 6+ messages in thread
From: Xin Zhao @ 2005-07-30 0:10 UTC (permalink / raw)
To: bert hubert, Xin Zhao, linux-kernel
Thanks. I will try. The only problem I have right now is I am using
Xenolinux instead of standard Linux kernel, I cannot see the option to
enable the frame pointer. But I will figure out how to enable that.
Again, thank you for your help!
Xin
an 7/29/05, bert hubert <bert.hubert@netherlabs.nl> wrote:
> On Fri, Jul 29, 2005 at 05:00:20PM -0400, Xin Zhao wrote:
> > Thanks for your reply.
> >
> > Below is the code that print the kernel calling trace:
>
> Can I suggest just turning on frame pointers like I suggested?
>
> If you say Y here the resulting kernel image will be slightly larger
> and slower, but it will give very useful debugging information.
> If you don't debug the kernel, you can say N, but we may not be able
> to solve problems without frame pointers.
>
> Good luck!
>
> --
> http://www.PowerDNS.com Open source, database driven DNS Software
> http://netherlabs.nl Open and Closed source services
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why dump_stack results different so much?
2005-07-30 0:10 ` Xin Zhao
@ 2005-07-30 11:52 ` bert hubert
0 siblings, 0 replies; 6+ messages in thread
From: bert hubert @ 2005-07-30 11:52 UTC (permalink / raw)
To: Xin Zhao; +Cc: linux-kernel
On Fri, Jul 29, 2005 at 08:10:32PM -0400, Xin Zhao wrote:
> Thanks. I will try. The only problem I have right now is I am using
> Xenolinux instead of standard Linux kernel, I cannot see the option to
> enable the frame pointer. But I will figure out how to enable that.
If you ever report something odd again, remember to inform the readers here
of any odd patches you are running with; they might be the *cause* of what
you are seeing!
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-07-30 11:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-07-29 20:27 Why dump_stack results different so much? Xin Zhao
2005-07-29 20:34 ` bert hubert
2005-07-29 21:00 ` Xin Zhao
2005-07-29 21:22 ` bert hubert
2005-07-30 0:10 ` Xin Zhao
2005-07-30 11:52 ` bert hubert
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox