perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <steve....@uk.radan.com>
Subject Problem with Apache::Reload in mp2?
Date Fri, 04 Feb 2005 13:03:57 GMT
The mp2 test suite contains a test for Apache::Reload, but it doesn't 
seem to test unloading a modules with an XS component, unless I'm 
missing something.

Applying the attached changes alters the test so that instead of 
unloading the tiny pure-Perl Apache::Reload::Test module, it now tries 
to unload the Storable module (having loaded it up earlier, of course).  
It also changes modperl_util.c for debugging purposes...

With these changes in place I now find that running "perl t/TEST 
modules/reload.t" crashes in test 3 (the one which is now trying to 
unload Storable).

I get an access violation on the HvNAME(stash_hv) call.  Unfortunately, 
I couldn't see where the prior sv_dump(val)'s output went, but walking 
through sv_dump() it seems to be saying

SV = IV(0x6c7a20c) at 0x7a388c8
    REFCNT = 1
    FLAGS = (IOK, pIOK)
    IV = -1

The access violation occurs because "stash_hv" is invalid (0xffffffff).  
Here's the stack trace:

modperl_package_clear_stash(interpreter * 0x04e47ed8, const char * 
0x0789e188) line 780
modperl_package_unload(interpreter * 0x04e47ed8, const char * 
0x0789e188) line 798 + 13 bytes
XS_List__Util_min(interpreter * 0x04e47ed8, cv * 0x06c9de3c) line 127 + 
24 bytes
Perl_pp_entersub(interpreter * 0x04e47ed8) line 2890 + 16 bytes
Perl_runops_debug(interpreter * 0x04e47ed8) line 1449 + 13 bytes
S_call_body(interpreter * 0x04e47ed8, op * 0x09e9fd4c, int 0) line 2298 
+ 13 bytes
Perl_call_sv(interpreter * 0x04e47ed8, sv * 0x07a3c744, long 4) line 
2216 + 15 bytes
modperl_callback(interpreter * 0x04e47ed8, modperl_handler_t * 
0x04eae760, apr_pool_t * 0x04ea0490, request_rec * 0x04ea04c8, 
server_rec * 0x0027c6b0, av * 0x06ca385c) line 100 + 17 bytes
modperl_callback_run_handlers(int 6, int 4, request_rec * 0x04ea04c8, 
conn_rec * 0x00000000, server_rec * 0x0027c6b0, apr_pool_t * 0x00000000, 
apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, int 1) line 261 + 35 bytes
modperl_callback_per_dir(int 6, request_rec * 0x04ea04c8, int 1) line 
370 + 34 bytes
modperl_response_handler_run(request_rec * 0x04ea04c8, int 1) line 978 + 
13 bytes
modperl_response_handler(request_rec * 0x04ea04c8) line 1018 + 11 bytes
ap_run_handler(request_rec * 0x04ea04c8) line 152 + 31 bytes
ap_invoke_handler(request_rec * 0x6ff095e6) line 367
ap_process_http_connection(conn_rec * 0x6ff0411f) line 250 + 6 bytes
ap_run_process_connection(conn_rec * 0x04e9a510) line 42 + 31 bytes
ap_process_connection(conn_rec * 0x04e9a510, void * 0x04e9a440) line 175 
+ 6 bytes
worker_main(long 2009300920) line 729
MSVCRT! 77c37fb8()

At this point, "this_stash" and "package" are both "Storable" and "key" 
is "nstore".

So why did GvSTASH(val) return 0xffffffff?  Probably because the SV 
"val" is apparently the IV "-1", rather than a GV which I thought every 
value in a stash was supposed to be.  I tried casting "val" to a GV like so:

    GV *val = (GV *)hv_iterval(stash, he);

but it made no difference.

Am I doing something completely wrong, or is there something amiss here?

Note that the problem, if there is one, does not affect all XS modules, 
e.g. using Digest::MD5, Encode or SDBM_File instead of Storable in the 
above all work fine, so it may not actually be anything to do with the 
XS component.

- Steve


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

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