You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Steve Hay <st...@uk.radan.com> on 2003/09/18 19:02:29 UTC
[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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 test failures
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
Steve Hay wrote:
> 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.
[...]
> 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.
So you and Randy are getting very close to the puzzle's solution, now all you
need is to make t/SMOKE working so you can find the test that causes the
messup (since it's probably some previously run test that messes things up for
these later tests).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org