linux-mips
[Top] [All Lists]

Re: How to detect STACKOVEFLOW on mips

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: How to detect STACKOVEFLOW on mips
From: Matt Fleming <matt@console-pimps.org>
Date: Mon, 5 Jul 2010 15:08:16 +0100
Cc: linux-mips@linux-mips.org, Adam Jiang <jiang.adam@gmail.com>
In-reply-to: <20100705133533.GA1262@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <AANLkTimL7YMyb2ahmTgl8dqV_DNfsROjDhLEDm4jyVWE@mail.gmail.com> <20100630145006.GA31938@linux-mips.org> <87zkycyyi2.fsf@linux-g6p1.site> <20100705105627.GA12699@linux-mips.org> <20100705130931.GA2968@console-pimps.org> <20100705133533.GA1262@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.18 (2008-05-17)
On Mon, Jul 05, 2010 at 02:35:33PM +0100, Ralf Baechle wrote:
> On Mon, Jul 05, 2010 at 02:09:31PM +0100, Matt Fleming wrote:
> 
> > > Which often isn't so helpful.  The alarm gets triggered on the last stack
> > > pointer decrement but according to murphy the overflow has happened 10
> > > levels up in the callchain.
> > 
> > Last decrement? The alarm should be triggered the next time the
> > function in which the overflow occurs makes a function call. I don't
> > see how you could go down a level of the callchain and not trigger the
> > alarm if the overflow has happened?
> 
> guilt()
> {
>       char array[6000];
> 
>       blurb(&array);
> }
> 
> blurb(void *p)
> {
>       frob(p);
> }
> 
> With the deep nesting of the current kernel there is a good chance a
> check in mcount will not be triggered in blurb() but possibly in frob
> or even further down the callchain.

Ah, I think I see what you mean. You're saying that you may not find
the culprit function using the massive amount of stack spac, which
eventually leads to the overflow? Yeah, that's a fair point. I think
if the mcount technique was used in conjunction with
CONFIG_DEBUG_STACK_USAGE it might be more helpful in that situation.

<Prev in Thread] Current Thread [Next in Thread>