perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philippe M. Chiasson" <go...@ectoplasm.org>
Subject Re: Problem with Apache::Reload in mp2?
Date Sun, 06 Feb 2005 06:13:07 GMT
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

Mime
View raw message