[mp2] Win32 test failures

I promised earlier today to report more detail of test failures in:

   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