Messages in this thread | | | Date | Tue, 23 Mar 1999 14:17:43 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: tracing a kernel stack corruption |
| |
On Tue, 23 Mar 1999, Fabien Klein wrote:
> Does anyone knows how to trace a kernel stack corruption error??
yes, you can use the IKD ('Integrated Kernel Debugging') patch, but maybe the solution is simpler than that:
> I use a program wich performs ioctl to an experimental network driver of > my own > At the end of this process ( when the release() function is called ), it > seems that the usual contents of the kernel_stack_page element > (0xdeadbeef) from the task_struct strucure has been crushed somewhere ( > I don t know how it is possible 'cause I don t play with any > task_struct...)
One important kernel programming rule, at most ~7K should be used as stack variables. (~4k on 2.0, thus a good guideline is to never allocate more than 3k). Most probably the problem is that you allocate some big structure on the kernel stack:
myioctl () { char buff [10000];
.... }
use kmalloc() instead.
if you cannot find it, then you can use IKD which has a small extension called 'stack status monitor', which simply saves the function's address that used the most stackspace. (/proc/stack_monitor, or something like that). Then you can work down all those functions that use too much stack.
-- mingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |