It looks like the problem is not so much that f->ctx et al gets zeroed, as that apr_pcalloc() returns something "under" f (namely, f->c->pool) as the zeroed memory, rather than a "new" area of memory. The fact that f->ctx et al gets zeroed is just a consequence of that.
Was it at all relevant that on the successful run filter->pool was 0xffffffff to start with? That value wouldn't normally just crop up by accident!
nice work steve. I think that adds a lot.
the implementation from apr_pcalloc (in apr_pools.h) says this
* Allocate a block of memory from a pool and set all of the memory to 0 #define apr_pcalloc(p, size) memset(apr_palloc(p, size), 0, size)
the thing that I don't get, though, is that later on apr_pools.c does this
#ifdef apr_pcalloc #undef apr_pcalloc #endif
... if ((mem = apr_palloc(pool, size)) != NULL) { memset(mem, 0, size); }
and there is at least one case in apr_palloc where it officially returns NULL.
my C isn't that strong, but is the #ifdef really undoing the first macro for everybody? my intuition tells me that it should be an #ifndef block instead...
It does the right thing, that macro is local to the .c file, all other .c files will see the macro from .h.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
