Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
From: "Sander Striker" <striker@apache.org>
To: <dev@apr.apache.org>
Subject: Pools debug WAS: RE: cvs commit: apr CHANGES STATUS
Date: Sat, 12 Jan 2002 10:34:25 +0100
Message-ID: <JLEGKKNELMHCJPNMOKHOGEBMFCAA.striker@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3C3F9F03.3040805@apache.org>
Importance: Normal

> From: Ian Holsman [mailto:ianh@apache.org]
> Subject: Re: cvs commit: apr CHANGES STATUS
> 
> Jeff Trawick wrote:
>> Ian Holsman <ianh@apache.org> writes:
>> 
>>> BTW turning on&off APR_POOL_DEBUG/
>>> requires a recompile now as well, as other functions are not
>>> defined like apr_pool_join.
>>>
>>>> Why can't APR_POOL_DEBUG do what it used to do (relatively quick to
>>>> switch on and off) and some other define (APR_POOL_DEBUG_VERBOSE
>>>> perhaps?) switch to saving __FILE__ and __LINE__?
>>>>
>> 
>> Put it another way...  what is the value add I get in return for
>> having to recompile everything?
> 
> first of all APR_POOL_DEBUG before this patch required a recompile.
> this is due to the apr_pool_join & apr_pool_lock functions defined
> in the header react differently according to this flag.
> 
> I agree that just being able to switch to a malloc/free allocator
> and use things like efence/purify is useful, and the flag for this
> should be defined in apr_pools.c itself.

Just define it externally, CPPFLAGS=-DAPR_POOL_DEBUG make
works wonders.  And actually, I wanted to put it in configure :)
--with-pools-debug=yes|no|verbose, or something like that.

This document is out of date since the code changes to pools,
but if you look at the bottom of the page, you can see that a
recompile was always neccesary, even with the previous code:
http://httpd.apache.org/docs-2.0/developer/debugging.html
 
>> Why couldn't the complete recompile be saved for folks that want
>> APR_POOL_DEBUG_VERBOSE?

It can't.  Hmmm, come to think of it, we actually can, but it
isn't nice.  It is possible to also provide the apr_pool_xxx
functions (without the _dbg postfix) in apr_pools.c when
APR_POOL_DEBUG is defined.  Those will not need the file and
line arguments.
 
> seems like we need 3 defines
> 
> 1. APR_USE_MALLOC -- for things like efence/purify

Which is what APR_POOL_DEBUG is for right now.  malloc is
_always_ used in debug mode, putting the main pools code
out of the game.

> 2. APR_MIDWAY -- for things like apr_pool_join/lock/line#s etc

Don't know about apr_pool_join, but apr_pool_lock is still a noop.
I never got around to re-implementing it.  Not sure what it should
look like yet.

> 3. APR_VERBOSE -- which dumps the stuff out to a log file.

I'd like to keep all defines to do with pools to start with
APR_POOL_xxx.  If it is more general than that, fine, but if
it is only used in the pools code, we shouldn't polute the
namespace.

> 2/3 are the ones which require a recompile of everything.

Maybe we should update the debugging document.

"If you are experiencing memory problems, make a copy of your
 tree.  Recompile the copy just like the original, but this
 time make sure to define APR_POOL_DEBUG..."

Something like that.  Then, at least, someone has still
got the failing tree (which could be usefull).  The DEBUG tree
can be used to identify the problem.

Sander