Re: memory analysis

[Joe Orton <jo...@redhat.com>]

On Thu, Sep 16, 2004 at 02:26:20AM -0400, Stephen Ince wrote:
> Hi,
>     I am trying to find memory errors in my application and I am having a
> hard time. I tried setting APR_POOL_DEBUG=2 but it is catching the errors.

Using --enable-pool-debug in conjunction with a malloc() checker like
ElectricFence is a good bet; this will catch heap buffer overruns (and
underruns if efence is configured appropriately).  To catch stack
overflows you need a smarter compiler, APR can't help with that.

ISTR someone once had a hack which enabled efence-like mprotect() stuff
inside apr_pools.c... hmmmm, Google says it was Greg but is refusing to
divulge actually patches.

joe

Re: memory analysis

[Stephen Ince <si...@opendemand.com>]

Joe,
    Thanx for the insight. The stack overflow is probabely impossible to
catch. I guess that's why it is dangerous to use buffers off the stack.

Steve
----- Original Message ----- 
From: "Joe Orton" <jo...@redhat.com>
To: "APR Development" <de...@apr.apache.org>
Sent: Thursday, September 16, 2004 4:01 AM
Subject: Re: memory analysis


> On Thu, Sep 16, 2004 at 02:26:20AM -0400, Stephen Ince wrote:
> > Hi,
> >     I am trying to find memory errors in my application and I am having
a
> > hard time. I tried setting APR_POOL_DEBUG=2 but it is catching the
errors.
>
> Using --enable-pool-debug in conjunction with a malloc() checker like
> ElectricFence is a good bet; this will catch heap buffer overruns (and
> underruns if efence is configured appropriately).  To catch stack
> overflows you need a smarter compiler, APR can't help with that.
>
> ISTR someone once had a hack which enabled efence-like mprotect() stuff
> inside apr_pools.c... hmmmm, Google says it was Greg but is refusing to
> divulge actually patches.
>
> joe
>