apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Ince" <si...@opendemand.com>
Subject Re: apr pool arch shortcoming: lack of pool validation API
Date Sun, 25 Jan 2004 19:54:22 GMT
Is there any documentation on how to debug these types of memory errors for
(APR)applications on windows.
I have been looking at mpatrol.

It looks like apr_pool is using mostly macros, so I assume a memory
management debugger that has a macro replacement for malloc would suffice.

Questions:
What is the best memory management debugger for windows, or linux?
What macros needs to be defined for the apr?
What are some general strategies or techniques for finding memory management
errors?

Steve





----- Original Message ----- 
From: "Sander Striker" <striker@apache.org>
To: "Stas Bekman" <stas@stason.org>
Cc: "APR Development" <dev@apr.apache.org>
Sent: Sunday, January 25, 2004 5:29 AM
Subject: Re: apr pool arch shortcoming: lack of pool validation API


> On Sun, 2004-01-25 at 01:57, Stas Bekman wrote:
> > Recently I've learned about an important feature lacking in apr pool
> > architecture - it's the ability to verify that the pool is still the
same pool
> > and wasn't destroyed or replaced by another pool.
> >
> > If I create a new pool and stash a pointer to it in 2 variables, it's
quite
> > possible that one variable will call apr_pool_destroy, the other won't
know
> > that the pool has been destroyed. As long as a new pool wasn't
allocated, the
> > other accessor will still be able to use the ghost pool, as if it was
there
> > for real. The moment a new pool will get allocated at the same memory
address,
> > the ghost accessor will wreck havoc operating on the pool that doesn't
belong
> > to it.
> >
> > I think what's needed is to store a unique signature every time a new
pool is
> > created somewhere in the pool and have the API to get and verify that
> > signature. If this functionality was in place, I could stash that
signature
> > along with the apr_pool_t pointer in my variables and before doing
something I
> > could verify whether I'm still talking to the correct pool.
> >
> > The situation when you have a ghost pointer is very real. Since the
parent
> > pool destroys all its child pools, the variables referencing these child
pools
> > may not know that the parent pool has been destroyed and still try to
use the
> > ghost pools.
> >
> > Thanks.
>
> This why there is a pool debugging mode.  In production no checks are
> made.  If you run in debug mode, with electric fence or valgrind, you'll
> flush out the type of bugs you mention easily (and a lot more).
>
> Sander
>


Mime
View raw message