You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@attglobal.net> on 2001/12/18 18:01:13 UTC
APR_POOL_DEBUG and apr_pool_tag()
apr_pool_tag() would seem to be very cheap in terms of space and
time as well as potentially useful for debugging problems in
production builds.
Does it really need to be noop-ed if APR_POOL_DEBUG isn't defined?
I'd like to see it always and I'd like to tweak Apache to use it in
more places.
I see that today apr_pool_tag() is almost the only thing controlled
via APR_POOL_DEBUG but I would imagine that folks will implement more
costly debug tools in the figure which you'd get with APR_POOL_DEBUG.
Thoughts?
(just fretting about the latest SIGHUP segfault with worker; pretty
likely that it is a pool misuse; it'd be nice to walk through the
coredump seeing "process", "pconf", "transaction", etc. yeah I can
define APR_POOL_DEBUG but what happens when APR_POOL_DEBUG gets too
expensive to use on a normal basis?)
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: APR_POOL_DEBUG and apr_pool_tag()
Posted by Jeff Trawick <tr...@attglobal.net>.
"David Reid" <dr...@jetnet.co.uk> writes:
> What about a similar thing to allow us to tag threads as well? the
> information could be included when spewing out debug information and may be
> useful.
maybe it should be a thread attribute?
This may not be necessary since there is a pointer to the thread start
routine in the apr_thread_t (at least on Unix). That would often be
enough. dunno
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: APR_POOL_DEBUG and apr_pool_tag()
Posted by David Reid <dr...@jetnet.co.uk>.
What about a similar thing to allow us to tag threads as well? the
information could be included when spewing out debug information and may be
useful.
Just a thought.
david
----- Original Message -----
From: "Jeff Trawick" <tr...@attglobal.net>
To: <de...@apr.apache.org>
Sent: Tuesday, December 18, 2001 5:01 PM
Subject: APR_POOL_DEBUG and apr_pool_tag()
> apr_pool_tag() would seem to be very cheap in terms of space and
> time as well as potentially useful for debugging problems in
> production builds.
>
> Does it really need to be noop-ed if APR_POOL_DEBUG isn't defined?
> I'd like to see it always and I'd like to tweak Apache to use it in
> more places.
>
> I see that today apr_pool_tag() is almost the only thing controlled
> via APR_POOL_DEBUG but I would imagine that folks will implement more
> costly debug tools in the figure which you'd get with APR_POOL_DEBUG.
>
> Thoughts?
>
> (just fretting about the latest SIGHUP segfault with worker; pretty
> likely that it is a pool misuse; it'd be nice to walk through the
> coredump seeing "process", "pconf", "transaction", etc. yeah I can
> define APR_POOL_DEBUG but what happens when APR_POOL_DEBUG gets too
> expensive to use on a normal basis?)
> --
> Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
RE: APR_POOL_DEBUG and apr_pool_tag()
Posted by Sander Striker <st...@apache.org>.
> From: Brian Pane [mailto:brian.pane@cnet.com]
> Sent: 18 December 2001 19:44
> To: dev@apr.apache.org
> Subject: Re: APR_POOL_DEBUG and apr_pool_tag()
>
>
> Jeff Trawick wrote:
>
> >"Sander Striker" <st...@apache.org> writes:
> >
> >>This sounds like good moment to introduce for APR_POOL_TAG.
> >>
> >
> >fine by me...
> >
>
> One of the things that made the original pool code difficult
> to maintain was that it had so many different ifdefs for
> debugging. I think it would be cleaner to leave out APR_POOL_TAG
> and just enable the non-noop version of apr_pool_tag() all the
> time. In fact, I think that any "non-performance-impacting"
> debug code in the new pools should be enabled by default, so
> that in the event of a crash we'll be able to gather some extra
> diagnostic information immediately, without having to first
> recompile with debug flags and wait for the crash to happen
> again.
>
> --Brian
Valid argument. I'll take care of it straight away.
Sander
Re: APR_POOL_DEBUG and apr_pool_tag()
Posted by Brian Pane <br...@cnet.com>.
Jeff Trawick wrote:
>"Sander Striker" <st...@apache.org> writes:
>
>>This sounds like good moment to introduce for APR_POOL_TAG.
>>
>
>fine by me...
>
One of the things that made the original pool code difficult
to maintain was that it had so many different ifdefs for
debugging. I think it would be cleaner to leave out APR_POOL_TAG
and just enable the non-noop version of apr_pool_tag() all the
time. In fact, I think that any "non-performance-impacting"
debug code in the new pools should be enabled by default, so
that in the event of a crash we'll be able to gather some extra
diagnostic information immediately, without having to first
recompile with debug flags and wait for the crash to happen
again.
--Brian
Re: APR_POOL_DEBUG and apr_pool_tag()
Posted by Jeff Trawick <tr...@attglobal.net>.
"Sander Striker" <st...@apache.org> writes:
> This sounds like good moment to introduce for APR_POOL_TAG.
fine by me...
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
RE: APR_POOL_DEBUG and apr_pool_tag()
Posted by Sander Striker <st...@apache.org>.
> From: trawick@rdu163-40-092.nc.rr.com
> [mailto:trawick@rdu163-40-092.nc.rr.com]On Behalf Of Jeff Trawick
> apr_pool_tag() would seem to be very cheap in terms of space and
> time as well as potentially useful for debugging problems in
> production builds.
>
> Does it really need to be noop-ed if APR_POOL_DEBUG isn't defined?
I don't know. I noop-ed it, because it was only likely to be
usefull when debugging. If people think otherwise we can put it
behind APR_POOL_TAG or something like that, or leave it on always.
> I'd like to see it always and I'd like to tweak Apache to use it in
> more places.
Yes. When working on sms I had a full set of changes for httpd. At
every pool create there was a tag. Got rid of the changes though when
we removed sms from the codebase.
> I see that today apr_pool_tag() is almost the only thing controlled
> via APR_POOL_DEBUG but I would imagine that folks will implement more
> costly debug tools in the figure which you'd get with APR_POOL_DEBUG.
Yes. Working on it. I have time in two days to round it up. It's
going to be very straight forward.
> Thoughts?
>
> (just fretting about the latest SIGHUP segfault with worker; pretty
> likely that it is a pool misuse; it'd be nice to walk through the
> coredump seeing "process", "pconf", "transaction", etc. yeah I can
> define APR_POOL_DEBUG but what happens when APR_POOL_DEBUG gets too
> expensive to use on a normal basis?)
This sounds like good moment to introduce for APR_POOL_TAG.
> --
> Jeff Trawick
Sander