On Thu, Feb 26, 2009 at 09:07:00PM +0100, max at bruningsystems.com wrote:
Jonathan Adams wrote:
On Thu, Feb 26, 2009 at 11:42:59AM -0800, Edward Pilatowicz wrote:
On Thu, Feb 26, 2009 at 01:42:24PM -0500, James Carlson wrote:
I just spent a little over a day debugging a stack
On Thu, Feb 26, 2009 at 03:11:04PM -0500, James Carlson wrote:
Alexandre Chartre writes:
That's a runtime problem so the compiler can not do anything (unless you
allocate an obviously too large structure on the stack), but this will
mainly depend on the code path and allocations on the
Jonathan Adams writes:
On Thu, Feb 26, 2009 at 09:07:00PM +0100, max at bruningsystems.com wrote:
There is a redzone page at the low end of all(?) kernel stacks. When it
is touched,
the system panics (better than overwriting other memory).
See the code for segkp_fault(0 in
Jonathan Adams writes:
On Thu, Feb 26, 2009 at 03:11:04PM -0500, James Carlson wrote:
The tool Ed mentioned is a new dcmd command: ::stackinfo (available
since
Nevada build 102), which shows kernel thread stack usage.
I'm talking about kmdb's stack itself. When that explodes,
Correction krs_cpustack is only used when entering kmdb, then it
uses kmdb_main_stack which is mdb_alloc'ed. You probably overflowed
this stack.
alex.
On 02/26/09 12:22, Alexandre Chartre wrote:
If I remember correctly, kmdb uses krs_cpustack from kaif_cpusave_t
structure as a stack (one
