On Tue, 16 Sep 2003, Stas Bekman wrote:
> Steve Hay wrote:
> > Re-running the tests as "perl t/TEST -verbose t/filter" fixes everything
> > except for filter/in_str_consume.t test 1, which still fails for me
> > (even with perl-5.8.1).
>
> that means that some previous tests affect the filter
> tests. t/SMOKE is good at finding the shortest sequence of
> tests that lead to the failure.
>
> But I'm a bit lost in the amount of mixed reports. Can you
> please report the filter/in_str_consume.t in a separate
> email/thread? Thanks.
>
> > What's that all about, then?
> >
> > Stas: In a previous mail you said, "I suspect that the problem has
> > surfaced after I have changed the number of running servers from one to
> > two to allow the proxy work. What happens if you make the proxy filter
> > skip and run the tests with only one server available? I bet they will
> > all work." Could I have that again in English please? What do you want
> > me to try?
>
> Sorry, that means, making that test skip as in the patch
> below. And then run:
>
> t/TEST -conf -maxclients 1
> t/TEST
Unfortunately, I still get the same crash when run this way.
The trace is the same as what I posted earlier - what seems
to happen is that, within src/modules/perl/modperl_filter.c,
- in modperl_output_filter_handler,
filter = modperl_filter_new(...);
is called, and the debugger reports some non-null value
for "filter".
- this then this gets passed to
status = modperl_run_filter(filter);
- within modperl_run_filter a handler is created via
handler = ((modperl_filter_ctx_t *)filter->f->ctx)->handler;
but the debugger reports that filter->f->ctx is null.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
