hooks/stacked_handlers2 modules/include
It turns out that the failures are very similar to those I've been seeing with
filter/both_str_con_add
so I thought I'd bring them all together.
There seems to be some kind of problem with running *both* t/api and t/apr before each of the failing tests: These commands all succeed (except for the unrelated failures in filter/in_str_consume and apr/perlio, neither of which crash Apache):
perl t/TEST t/api t/filter perl t/TEST t/apr t/filter perl t/TEST t/api t/hooks perl t/TEST t/apr t/hooks perl t/TEST t/api t/modules perl t/TEST t/apr t/modules
but these commands all fail (and crash Apache) on the test scripts indicated above:
perl t/TEST t/api t/apr t/filter perl t/TEST t/api t/apr t/hooks perl t/TEST t/api t/apr t/modules
In the case of t/filter I get an Access Violation at
modperl_handler_t *handler =
((modperl_filter_ctx_t *)filter->f->ctx)->handler;in modperl_run_filter(). It seems that filter->f->ctx was NULLed by the prior call to apr_pcalloc() within modperl_filter_new(). Here's a stack trace:
=====
modperl_run_filter(modperl_filter_t * 0x008e1cb8) line 378 + 9 bytes
modperl_output_filter_handler(ap_filter_t * 0x008e23c8, apr_bucket_brigade * 0x008e24a0) line 767 + 9 bytes
ap_pass_brigade(ap_filter_t * 0x008e23c8, apr_bucket_brigade * 0x008e24a0) line 550 + 16 bytes
XS_Apache__Filter_pass_brigade(interpreter * 0x01838014, cv * 0x00fe9904) line 197 + 14 bytes
Perl_pp_entersub(interpreter * 0x01838014) line 2818 + 16 bytes
Perl_runops_debug(interpreter * 0x01838014) line 1434 + 13 bytes
S_call_body(interpreter * 0x01838014, op * 0x02acfde0, int 0) line 2193 + 13 bytes
Perl_call_sv(interpreter * 0x01838014, sv * 0x01133040, long 4) line 2111 + 15 bytes
modperl_callback(interpreter * 0x01838014, modperl_handler_t * 0x00895ad0, apr_pool_t * 0x008e1cb8, request_rec * 0x00000000, server_rec * 0x00894c40, av * 0x00f01824) line 69 + 17 bytes
modperl_callback_run_handlers(int 0, int 5, request_rec * 0x00000000, conn_rec * 0x008e1db8, server_rec * 0x00894c40, apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, int 1) line 207 + 35 bytes
modperl_callback_connection(int 0, conn_rec * 0x008e1db8, int 1) line 299 + 34 bytes
modperl_process_connection_handler(conn_rec * 0x008e1db8) line 77 + 13 bytes
ap_run_process_connection(conn_rec * 0x008e1db8) line 85 + 78 bytes
ap_process_connection(conn_rec * 0x008e1db8, void * 0x008e1cf0) line 213
worker_main(long 1) line 731
_threadstartex(void * 0x0028d328) line 212 + 13 bytes
KERNEL32! 77e7d33b()
=====
In the case of t/hooks I also get an Access Violation at
modperl_handler_t *handler =
((modperl_filter_ctx_t *)filter->f->ctx)->handler;in modperl_run_filter(). Again, filter->f->ctx is NULL, hence the access violation. Here's a stack trace:
=====
modperl_run_filter(modperl_filter_t * 0x03362240) line 378 + 9 bytes
modperl_output_filter_handler(ap_filter_t * 0x03362af8, apr_bucket_brigade * 0x03361340) line 767 + 9 bytes
ap_pass_brigade(ap_filter_t * 0x03362af8, apr_bucket_brigade * 0x03361340) line 550 + 16 bytes
modperl_wbucket_pass(modperl_wbucket_t * 0x03358160, const char * 0x03358164, unsigned int 32, int 1) line 165
modperl_wbucket_flush(modperl_wbucket_t * 0x03358160, int 1) line 183 + 26 bytes
mpxs_Apache__RequestRec_print(interpreter * 0x022e6d84, long 2, sv * * 0x024b442c, sv * * 0x024b4428) line 78 + 130 bytes
XS_Apache__RequestRec_print(interpreter * 0x022e6d84, cv * 0x024279c0) line 115 + 24 bytes
Perl_pp_entersub(interpreter * 0x022e6d84) line 2818 + 16 bytes
Perl_runops_debug(interpreter * 0x022e6d84) line 1434 + 13 bytes
S_call_body(interpreter * 0x022e6d84, op * 0x02acfd5c, int 0) line 2193 + 13 bytes
Perl_call_sv(interpreter * 0x022e6d84, sv * 0x01286158, long 4) line 2111 + 15 bytes
modperl_callback(interpreter * 0x022e6d84, modperl_handler_t * 0x00894480, apr_pool_t * 0x0084c550, request_rec * 0x0084c588, server_rec * 0x00890a98, av * 0x0278930c) line 69 + 17 bytes
modperl_callback_run_handlers(int 6, int 1, request_rec * 0x0084c588, conn_rec * 0x00000000, server_rec * 0x00890a98, apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, int 1) line 207 + 35 bytes
modperl_callback_per_dir(int 6, request_rec * 0x0084c588, int 1) line 283 + 34 bytes
modperl_response_handler_run(request_rec * 0x0084c588, int 1) line 847 + 13 bytes
modperl_response_handler(request_rec * 0x0084c588) line 869 + 11 bytes
ap_run_handler(request_rec * 0x0084c588) line 195 + 78 bytes
ap_invoke_handler(request_rec * 0x0084c588) line 401 + 9 bytes
ap_process_request(request_rec * 0x0084c588) line 288 + 9 bytes
ap_process_http_connection(conn_rec * 0x008e3df0) line 293 + 9 bytes
ap_run_process_connection(conn_rec * 0x008e3df0) line 85 + 78 bytes
ap_process_connection(conn_rec * 0x008e3df0, void * 0x008e3d28) line 213
worker_main(long 1) line 731
_threadstartex(void * 0x0028d328) line 212 + 13 bytes
KERNEL32! 77e7d33b()
=====
Finally, in the case of t/modules I get an Access Violation at
active = pool->active;
in apr_palloc() (Apache's srclib\apr\memory\unix\apr_pools.c, line 621). The value of pool there is not NULL, but the MSVC debugger won't expand the structure in the "Variables" window, which is (I think) normally an indication that it is uninitialised garbage. Here's a stack trace:
=====
apr_palloc(apr_pool_t * 0x434f4d53, unsigned int 280) line 621 + 3 bytes
apr_table_make(apr_pool_t * 0x434f4d53, int 8704537) line 419 + 14 bytes
ap_add_common_vars(request_rec * 0x0335d208) line 186 + 22 bytes
modperl_env_request_populate(interpreter * 0x0224e5dc, request_rec * 0x0335d208) line 171
modperl_response_handler_cgi(request_rec * 0x0335d208) line 899 + 13 bytes
ap_run_handler(request_rec * 0x0335d208) line 195 + 78 bytes
ap_invoke_handler(request_rec * 0x0335d208) line 401 + 9 bytes
ap_run_sub_req(request_rec * 0x0335d208) line 1893 + 9 bytes
handle_include(include_filter_ctx * 0x008f02f0, apr_bucket_brigade * * 0x02acfe6c, request_rec * 0x0084c588, ap_filter_t * 0x0084dff0, apr_bucket * 0x0091ddb0, apr_bucket * * 0x02acfdfc) line 1335 + 16 bytes
send_parsed_content(apr_bucket_brigade * * 0x02acfe6c, request_rec * 0x0084c588, ap_filter_t * 0x0084dff0) line 3111 + 30 bytes
includes_filter(ap_filter_t * 0x0084dff0, apr_bucket_brigade * 0x033623d8) line 3430 + 17 bytes
ap_pass_brigade(ap_filter_t * 0x0084dff0, apr_bucket_brigade * 0x0084e148) line 550 + 16 bytes
default_handler(request_rec * 0x0084c588) line 3558 + 19 bytes
ap_run_handler(request_rec * 0x0084c588) line 195 + 78 bytes
ap_invoke_handler(request_rec * 0x0084c588) line 401 + 9 bytes
ap_process_request(request_rec * 0x0084c588) line 288 + 9 bytes
ap_process_http_connection(conn_rec * 0x008eff40) line 293 + 9 bytes
ap_run_process_connection(conn_rec * 0x008eff40) line 85 + 78 bytes
ap_process_connection(conn_rec * 0x008eff40, void * 0x008efe78) line 213
worker_main(long 1) line 731
_threadstartex(void * 0x0028d328) line 212 + 13 bytes
KERNEL32! 77e7d33b()
=====
So there you have it. All we need to do now is work out what's wrong with t/api + t/apr :-) Over to someone else for that, I'm afraid, 'cos I haven't got clue.
- Steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
