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...
oh, and I'm only guessing this is the same implementation on win32, despite apr_pools.c living in memory/unix?
--Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
