Here are some results for running the t/filter tests with modperl_filter_new as
modperl_filter_new(*f, *bb, mode, input_mode, block, readbytes) { 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)); ... }
with inserting a breakpoint just before and just after the apr_pcalloc() call. It consistently fails on the 4th pass through modperl_filter_new:
1.
Before: f: 0x0142f7e8 f->c: 0x0142f2f0 f->c->pool: 0x0142f1f0 bb: 0x0142f9e0 mode: 0 input_mode: 1 block: 0 readbytes: 8192 p: 0x0142f1f0 (= f->c->pool) filter: null
After: filter: 0x024f7ed8 the rest unchanged
2.
Before: f: 0x0142f908 f->c: 0x0142f2f0 f->c->pool: 0x0142f1f0 bb: 0x0142f9e0 mode: 1 input_mode: 0 block: 0 readbytes: 0 p: 0x0142f1f0 (= f->c->pool) filter: 0x0258f730
After: filter: 0x025217c0 the rest unchanged
3.
Before: f: 0x0142f7e8 f->c: 0x0142f2f0 f->c->pool: 0x0142f1f0 bb: 0x0142f9e0 mode: 0 input_mode: 1 block: 0 readbytes: 8192 p: 0x0142f1f0 (= f->c->pool) filter: null
After: filter: 0x025217c0 the rest unchanged
4.
Before: f: 0x0142f908 f->c: 0x0142f2f0 f->c->pool: 0x0142f1f0 bb: 0x0142f9e0 mode: 1 input_mode: 0 block: 0 readbytes: 0 p: 0x0142f1f0 (= f->c->pool) filter: 0x0258f6d0
After: filter: 0x0142f1f0 (= p = f->c->pool before apr_pcalloc) f: 0x0142f908 f->c: null f->c->pool: null
Does anything jump out as being wrong, leading up to f->c becoming null?
Interesting. So the problem happens in the output filter.
So we have a sequence of:
1) input filter 2) output filter 3) input filter 4) output filter
What strikes me odd is that 'filter' is already pointing to some memory block but only in the output filter (2, 4), it's null in the input filter (1, 3).
Does the problem disappear if you remove the input filter:
- $c->add_input_filter(\&in_filter); + #$c->add_input_filter(\&in_filter);
if you put it back and remove the output filter?
- $c->add_output_filter(\&in_filter); + #$c->add_output_filter(\&in_filter);
each should be invoked 3 times.
Now have you tried descending into apr_pcalloc and seeing when the address stored in f->c->pool is returned as the allocated memory's address, sounds like a bug in apr_pcalloc on win32.
Also it'd be interesting to see the trace =f, if you can get it.
__________________________________________________________________ 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]
