On Thu, 18 Sep 2003, Stas Bekman wrote:
So did you look at the value of f->ctx before and after the apr_pcalloc() call on line 228 and that's when it has changed? are you sure that your compiler reports the line number correctly? Sometimes with an optimized code it may report wrong lines. e.g. I'd suggest to change: modperl_filter_t *filter = apr_pcalloc(p, sizeof(*filter));
to:
modperl_filter_t *filter; filter = apr_pcalloc(p, sizeof(*filter));
I find the same thing as Steve concerning this change: within modperl_run_filter(), filter->f->ctx is null.
I hope I'm reading this right, but I tried the following.
Within modperl_output_filter_handler(), I had
....
else {
p = f->r ? f->r->pool : f->c->pool;
filter = modperl_filter_new(f, ....);
status = modperl_run_filter();
}
Just after the
p = f->r ? f->r->pool : f->c->pool;
line, p has a value 0x0142de30, f is 0x0142e548, and
f->ctx, f->r and f->c are all null.
That's is not quite possible. If f->c == NULL, how come f->c->pool didn't segfault? f->r should be null since we are inside a connection, no r objects there.
It then calls modperl_filter_new(), within which I had 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)); At the line p = f->r ? f->r->pool : f->c->pool; p has a value 0x0142de30, f is 0x0142e548, and f->r and f->c are null, all as before. After the call filter = (modperl_filter_t *) apr_pcalloc(p, sizeof(modperl_filter_t)); filter has a value 0x0142de30, which is the same as p of before, and indeed filter->pool is 0x0142de30.
Does this help at all?
Certainly. It is possible that the memory pool is messed up. If you change apr_pcalloc with apr_palloc does it still happen (if it doesn't it will crash elsewhere, since that just proves that apr_pcalloc allocates the already allocated memory). the next step would be to enable apr_pool debug tracing :(
I tried with apr_palloc, and, as you say, it crashes earlier.
right, because some code relies on apr_pcalloc to initialize the struct's members to zero.
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 just for this test.
__________________________________________________________________ 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]
