perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <steve....@uk.radan.com>
Subject Re: t/perl/ithreads.t revisited
Date Fri, 10 Dec 2004 18:14:22 GMT
Stas Bekman wrote:

>Steve Hay wrote:
>  
>
>>Attached (hopefully) is a new tarball with a (simplified) 
>>HOW_TO_REPRODUCE file, and hash_attack.pm moved to t/lib/
>>    
>>
>
>Your t/conf/extra.conf.in has hardcoded path and you miss PerlModule 
>Apache2. so it should be:
>
>PerlSwitches -I@ServerRoot@
>PerlSwitches -I@ServerRoot@/response
>PerlSwitches -I@ServerRoot@/lib
>PerlModule Apache2
>PerlModule Apache::RequestRec
>PerlModule Apache::TestHandler
>PerlModule APR::Table
>PerlModule TestPerl::hash_attack
>  
>
OK.  New tarball attached for future ease of reference.  Still fails as 
before for me.

>As expected, I get no problem with this setup. :(
>
I've been walking through things in the debugger, and I've determined 
that it crashes in ithreads.pm while trying to require threads.pm.

I note that ithreads.pm contains this comment:

    # threads must have been preloaded at the server startup for this
    # test (this is done at t/conf/modperl_extra.pl)
    require threads;

but the skeleton httpd.conf doesn't do this.  I added a "PerlModule 
threads" line to my extra.conf and tried again, but it didn't fix it :(

The full mp2 test suite's actual modperl_extra.pl doesn't seem to 
contain anything that loads threads either :-s  Is something missing 
here, or is that comment merely bogus?

Some more detail on where it crashes:

A while before the crash I have this call stack:

Perl_yyparse(interpreter * 0x021ce0f4) line 380
S_doeval(interpreter * 0x021ce0f4, int 0, op * * 0x00000000, cv * 
0x00000000, unsigned long 11501) line 2817 + 9 bytes
Perl_pp_require(interpreter * 0x021ce0f4) line 3314 + 102 bytes
modperl_pp_require(interpreter * 0x021ce0f4) line 69 + 10 bytes
Perl_runops_debug(interpreter * 0x021ce0f4) line 1442 + 13 bytes
S_call_body(interpreter * 0x021ce0f4, op * 0x04a3fd40, int 0) line 2288 
+ 13 bytes
Perl_call_sv(interpreter * 0x021ce0f4, sv * 0x02b240e8, long 4) line 
2206 + 15 bytes
modperl_callback(interpreter * 0x021ce0f4, modperl_handler_t * 
0x008fa698, apr_pool_t * 0x008eb3f8, request_rec * 0x008eb430, 
server_rec * 0x0029ce20, av * 0x02ad69ec) line 102 + 17 bytes
modperl_callback_run_handlers(int 6, int 4, request_rec * 0x008eb430, 
conn_rec * 0x00000000, server_rec * 0x0029ce20, apr_pool_t * 0x00000000, 
apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, int 1) line 263 + 35 bytes
modperl_callback_per_dir(int 6, request_rec * 0x008eb430, int 1) line 
353 + 34 bytes
modperl_response_handler_run(request_rec * 0x008eb430, int 1) line 963 + 
13 bytes
modperl_response_handler(request_rec * 0x008eb430) line 1003 + 11 bytes
ap_run_handler(request_rec * 0x008eb430) line 152 + 78 bytes
ap_invoke_handler(request_rec * 0x008eb430) line 358 + 9 bytes
ap_process_request(request_rec * 0x008eb430) line 246 + 9 bytes
ap_process_http_connection(conn_rec * 0x008e73f8) line 250 + 9 bytes
ap_run_process_connection(conn_rec * 0x008e73f8) line 42 + 78 bytes
ap_process_connection(conn_rec * 0x008e73f8, void * 0x008e7328) line 177
worker_main(long 1) line 720
_threadstartex(void * 0x0029da38) line 212 + 13 bytes
KERNEL32! 77e7d33b()

where "name" in the Perl_pp_require() is "threads.pm".  Stepping ouf of 
there back to Perl_runops_debug() I can then go back into 
Perl_pp_require() twice more: once for Exporter.pm, then for DynaLoader.pm.

After that, it's a long trawl through the various ops (?) in the main 
loop within Perl_runops_debug().  Shortly before the crash we go into 
pp_method_named(); going into S_method_common() I see that the "name" is 
"bootstrap".  We then have these other ops:

pp_entersub
pp_nextstate
pp_pushmark
pp_gv
pp_rv2av
pp_pushmark
pp_gv
pp_rv2av
pp_aassign
pp_nextstate
pp_pushmark
pp_aelemfast
pp_pushmark
pp_gvsv
pp_aassign
pp_nextstate
pp_pushmark
pp_gv
pp_rv2av
pp_gvsv

It crashes within that last call, but I didn't catch where :(  I'll try 
again next week.

Anyway, you can see that threads.pm contains:

require Exporter;
require DynaLoader;
[...]
bootstrap threads $VERSION;

and at this stage threads.dll has not been loaded by Apache.exe, so it 
is obviously during the loading of that DLL that it crashes.

- Steve


------------------------------------------------
Radan Computational Ltd.

We would like to take this opportunity to wish all our customers, suppliers and colleagues
seasons greetings.  We will not be sending corporate greetings cards this year.  Instead,
we will be making a donation to charity.

The information contained in this message and any files transmitted with it are confidential
and intended for the addressee(s) only.  If you have received this message in error or there
are any problems, please notify the sender immediately.  The unauthorized use, disclosure,
copying or alteration of this message is strictly forbidden.  Note that any views or opinions
presented in this email are solely those of the author and do not necessarily represent those
of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached
files for viruses: Radan Computational will accept no liability for any damage caused by any
virus transmitted by this email.
Mime
View raw message