You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Stas Bekman <st...@stason.org> on 2004/01/25 01:57:44 UTC
apr pool arch shortcoming: lack of pool validation API
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.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apr pool arch shortcoming: lack of pool validation API
Posted by Stephen Ince <si...@opendemand.com>.
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" <st...@apache.org>
To: "Stas Bekman" <st...@stason.org>
Cc: "APR Development" <de...@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
>
Re: apr pool arch shortcoming: lack of pool validation API
Posted by Stas Bekman <st...@stason.org>.
Sander Striker wrote:
> 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).
I know about the debug mode. But I don't think this is suitable to all. We
provide a perl API to apr_pool_*. Many users of this API aren't sophisticated
enough to compile things (they usually use precompiled rpm provided by their
distro), not talking about using EF or valgrind. These users may write code,
where a parent pool will be nuked and their code will still try to access
child pools that are no longer there. As mentioned above this may or may not
work for them at different times. Therefore I was thinking that we could
provide an optional or mandatory instrumentation to verify the pool's validity
before it can be used.
At the moment I've rewritten our APR glue implementation using some perl
magic, so that it knows to invalidate any objects pointing to a pool, if the
latter is getting destroyed directly or indirectly (via parent destroy), so I
think our users are safe. But others may still find the validation API in a
non-debug mode to be handy or even crucial. Since I have the workaround for
this issue, it's OK if it's not added/exposed at the moment, but this is
something that you may want to add in the future.
When I was thinking about it, I came to a conclusion that I could implement
the signature validation mechanism by myself, by simply storing a unique
string via apr_pool_user_data_set in the pool, and in the object. And compare
the two before accessing the pool. So apr_pool could save me the trouble of
creating this signature and giving me a wrapper to create/read it. I think
that's all is needed. But may be there are more efficient ways to accomplish
the validation that I haven't thought about.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apr pool arch shortcoming: lack of pool validation API
Posted by Sander Striker <st...@apache.org>.
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