perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <>
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 moved to t/lib/
>Your t/conf/ 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 while trying to require

I note that contains this comment:

    # threads must have been preloaded at the server startup for this
    # test (this is done at t/conf/
    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 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 "".  Stepping ouf of 
there back to Perl_runops_debug() I can then go back into 
Perl_pp_require() twice more: once for, then for

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:


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

Anyway, you can see that 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.
View raw message