linux-mips
[Top] [All Lists]

Re: How to detect STACKOVEFLOW on mips

To: Matt Fleming <matt@console-pimps.org>
Subject: Re: How to detect STACKOVEFLOW on mips
From: Ralf Baechle <ralf@linux-mips.org>
Date: Mon, 5 Jul 2010 14:35:33 +0100
Cc: linux-mips@linux-mips.org, Adam Jiang <jiang.adam@gmail.com>
In-reply-to: <20100705130931.GA2968@console-pimps.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>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.20 (2009-08-17)
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.

  Ralf

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