On Fri, 19 Sep 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > Here are some results for running the t/filter tests
[ .. ]
> 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.
No, the same thing occurs in both cases - passing into
modperl_filter_new() 4 times, and on the 4th, f->c and
friends are all set to null.
> 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.
I'll look into that.
> Also it'd be interesting to see the trace =f, if you can get it.
^^^^
I'm not quite sure what that is - the apache filter f?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
