On Thu, 18 Sep 2003, Stas Bekman wrote:
[ ... ]
> so basically we always work with f->c->pool here. please
> check that it's the same value at the beginning of the run
> and continues to be the same as you go. It definitely
> can't be null at any given point. to simplify debugging
> you can even replace all places
>
> p = f->r ? f->r->pool : f->c->pool;
>
> with:
>
> p = f->c->pool;
Of course, you're right that f->c->pool isn't null at
the start of modperl_filter_new() - I was reading the
table wrong. I think I got it now, though, and the
problem does seem to be in the apr_pcalloc() call.
For modperl_filter_new():
apr_pool_t *p;
modperl_filter_t *filter;
p = f->r ? f->r->pool : f->c->pool;
filter = (modperl_filter_t *)
apr_pcalloc(p, sizeof(modperl_filter_t));
before the apr_pcalloc() call, f->c->pool is defined, and p
is set equal to it (f->r is null). However, sometimes what
happens right after the apr_pcalloc() call is that f->r,
f->c, ... of f get set to null (including f->ctx, which
causes the crash in modperl_run_filter), and filter gets set
to the value of p.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
