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" <[EMAIL PROTECTED]> To: "Stas Bekman" <[EMAIL PROTECTED]> Cc: "APR Development" <[email protected]> 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 >
