Randy Kobes wrote:Me too.
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.
The modperl_output_filter_handler in code goes:
if (((modperl_filter_ctx_t *)f->ctx)->sent_eos) { MP_TRACE_f(MP_FUNC, MP_FILTER_NAME_FORMAT "write_out: EOS was already sent, " "passing through the brigade\n", MP_FILTER_NAME(f)); return ap_pass_brigade(f->next, bb); } else { filter = modperl_filter_new(f, bb, MP_OUTPUT_FILTER_MODE, 0, 0, 0); status = modperl_run_filter(filter); }
So ((modperl_filter_ctx_t *)f->ctx) is non-NULL, when it checks for sent_eos, right? Otherwise it'll segfault right there. Then it goes through modperl_filter_new which simply stashes f into filter->f. When it comes back (modperl_filter_ctx_t *)filter->f->ctx) should be non-null as well. Is it?
I've put a breakpoint on line 763 (the modperl_filter_new() call) of modperl_filter.c, and I attach to the Apache process when the both_str_con_add.t test starts (I put a sleep 30; into it to give me time to catch it.)
When the debugger first stops on the breakpoint I have:
f = 0x008e23c8 f->ctx = 0x008e23c8 filter = 0x0000000c [garbage]
After the modperl_filter_new() call f and f->ctx are unchanged, but filter is now 0x033552b0 and it has a new filter->f member which is 0x008e23c8.
So far so good, and sure enough the modperl_run_filter() call goes OK: filter->f->ctx is 0x008e23b8, handler gets set to 0x008e23a0, and the function returns 14716076.
I then let the debugger continue and it soon stops again on the breakpoint. Initially the values are all as before:
f = 0x008e23c8 f->ctx = 0x008e23c8 filter = 0x0000000c [garbage]
But now after the modperl_filter_new() call only f is unchanged: f->ctx is changed to 0x00000000 this time, and filter to 0x008e1cb8 (with a filter->f member of 0x008e23c8).
So this time, of course, modperl_run_filter() fails when trying to set handler because filter->f->ctx is NULL.
I re-ran everything and this time stepped into modperl_filter_new() on the second call to it. It seems that the apr_pcalloc() call on line 228 of modperl_filter.c is what changes f->ctx from 0x008e23c8 to 0x00000000.
Does this help at all?
- Steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
