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 2005/02/04 14:03:57 UTC
Problem with Apache::Reload in mp2?
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.
Re: Problem with Apache::Reload in mp2?
Posted by Steve Hay <st...@uk.radan.com>.
Philippe M. Chiasson wrote:
>Joe Schaefer wrote:
>
>
>>"Philippe M. Chiasson" <go...@ectoplasm.org> writes:
>>
>>[...]
>>
>>
>>
>>
>>>But this is where I get confused. The entry for 'freeze'
>>>doesn't quite look right.
>>>
>>>SV = IV(0x80acb4) at 0x815f30
>>> REFCNT = 1
>>> FLAGS = (IOK,pIOK)
>>> IV = -1
>>>
>>>
>>I think that represents a declared, but not yet defined, subroutine:
>>
>> % perl -MDevel::Peek -wle 'sub foo; Dump $::{foo}'
>> SV = IV(0x521888) at 0x521f50
>> REFCNT = 1
>> FLAGS = (IOK,pIOK)
>> IV = -1
>>
>>
>
>Yes! Joe, many thanks, that explains it!
>
>Good, that also means that my suggested patch is correct.
>
Indeed -- it fixes it for me too.
Thanks to you both.
- 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Problem with Apache::Reload in mp2?
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Joe Schaefer wrote:
> "Philippe M. Chiasson" <go...@ectoplasm.org> writes:
>
> [...]
>
>
>>But this is where I get confused. The entry for 'freeze'
>>doesn't quite look right.
>>
>>SV = IV(0x80acb4) at 0x815f30
>> REFCNT = 1
>> FLAGS = (IOK,pIOK)
>> IV = -1
>
> I think that represents a declared, but not yet defined, subroutine:
>
> % perl -MDevel::Peek -wle 'sub foo; Dump $::{foo}'
> SV = IV(0x521888) at 0x521f50
> REFCNT = 1
> FLAGS = (IOK,pIOK)
> IV = -1
Yes! Joe, many thanks, that explains it!
Good, that also means that my suggested patch is correct. Now I just want to find
the Perl code that deals with declared, not yet defined subroutines for my own
personal education.
Thanks.
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
Re: Problem with Apache::Reload in mp2?
Posted by Joe Schaefer <jo...@sunstarsys.com>.
"Philippe M. Chiasson" <go...@ectoplasm.org> writes:
[...]
> But this is where I get confused. The entry for 'freeze'
> doesn't quite look right.
>
> SV = IV(0x80acb4) at 0x815f30
> REFCNT = 1
> FLAGS = (IOK,pIOK)
> IV = -1
I think that represents a declared, but not yet defined, subroutine:
% perl -MDevel::Peek -wle 'sub foo; Dump $::{foo}'
SV = IV(0x521888) at 0x521f50
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = -1
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Problem with Apache::Reload in mp2?
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Steve Hay wrote:
> 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.
It's supposed to do it's honest best to reload anything, XS modules included.
If it doesn't, than it's a bug.
> 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 was able to reproduce this. Seems it's got to do with XSUBs as far as
I can tell.
> 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:
In short, seems it has to do with XSUB stash entries being somewhat different
(I am not entirely sure yet what's going on)
> [...]
>
> Am I doing something completely wrong, or is there something amiss here?
Definitely something amiss here. Seems there can be things in a stash beyond
GVPVs as can be easily seen here:
$>perl -MStorable -MDevel::Peek -e'Dump($Storable::{AUTOLOAD}); Dump($Storable::{freeze})'
SV = PVGV(0x106b40) at 0x80c124
REFCNT = 1
FLAGS = (GMG,SMG,MULTI,ASSUMECV,IN_PAD)
IV = 0
NV = 0
MAGIC = 0x106b80
MG_VIRTUAL = &PL_vtbl_glob
MG_TYPE = PERL_MAGIC_glob(*)
MG_OBJ = 0x80c124
NAME = "AUTOLOAD"
NAMELEN = 8
GvSTASH = 0x80bf98 "Storable"
GP = 0x107440
[...]
CV = 0x8101d4
[...]
EGV = 0x80c124 "AUTOLOAD"
Exactly what one would expect in a stash, a GP with a CV slot filled with the AUTOLOAD sub.
But this is where I get confused. The entry for 'freeze' doesn't quite look right.
SV = IV(0x80acb4) at 0x815f30
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = -1
Dunno if someone with more Perl-foo care to explain this one to me.
> 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.
I am not sure how this bug is triggered (something to investigate further), but
in the meantime, give this patch a spin:
Index: src/modules/perl/modperl_util.c
===================================================================
--- src/modules/perl/modperl_util.c (revision 151479)
+++ src/modules/perl/modperl_util.c (working copy)
@@ -773,12 +773,11 @@
key = hv_iterkey(he, &len);
if (MP_SAFE_STASH(key, len)) {
SV *val = hv_iterval(stash, he);
- char *this_stash = HvNAME(GvSTASH(val));
/* The safe thing to do is to skip over stash entries
* that don't come from the package we are trying to
* unload
*/
- if (strcmp(this_stash, package) == 0) {
+ if (GvSTASH(val) == stash) {
hv_delete(stash, key, len, G_DISCARD);
}
}
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5