From: Ben Morrow on

Quoth Ted Byers <r.ted.byers(a)gmail.com>:
> On May 19, 6:54�pm, Ben Morrow <b...(a)morrow.me.uk> wrote:
> > Quoth Ted Byers <r.ted.by...(a)gmail.com>:
> >
> > > Trace:
> > > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/
> > > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/
> > > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485
> > > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485
> >
> > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/
> > > Win32/TieRegistry.pm line 1485, &#60;DATA&#62; line 335 during global
> > > destruction.
> >
> > > Compilation finished at Wed May 19 16:41:23
> >
> > Am I correct that line 1485 of your copy of Win32/TieRegistry.pm is the
> > last line here?
> >
> > � � sub DESTROY
> > � � {
> > � � � � my $self= shift(@_);
> > � � � � return � if �tied(%$self);
> > � � � � my $unload;
> > � � � � eval { $unload= $self->{UNLOADME}; 1 }
> >
> > If so I can't see how that could be calling tie magic, since the code's
> > just checked that it *isn't* tied. In any case, back up your copy of
> > Win32/TieRegistry.pm and add
> >
> > � � use Devel::Peek ();
> > � � use Carp ();
> > � � Devel::Peek::Dump($self);
> > � � Carp::confess("huh?");
> >
> > just before that line, and post the result.
>
> I hadn't noticed that, but I was out of my depth as I have never used
> the tie magic, and didn't know which of the packages I used would or
> why.
>
> In any event, here is the output after adding the four lines you
> suggest:
>
<snip>
> SV = RV(0x22c15b0) at 0x22c15a4
> REFCNT = 1
> FLAGS = (PADMY,ROK)
> RV = 0x1c53074
> SV = PVHV(0x1e45c4c) at 0x1c53074
> REFCNT = 2
> FLAGS = (OBJECT,SHAREKEYS)
> STASH = 0x1f5b01c "Win32::TieRegistry"
> ARRAY = 0x222f58c (0:14, 1:14, 2:4)
> hash quality = 121.5%
> KEYS = 22
> FILL = 18
> MAX = 31
> RITER = -1
> EITER = 0x0

OK, so the hash definitely isn't tied. (If it had been there would have
been a whole MAGIC section, including the line

MG_TYPE = PERL_magic_tied(P)

..)

Can you confirm that the code does in fact get as far as l1485, and
doesn't get any further? (Take out the 'confess', and put a 'warn'
before 'eval { $unload=...' and another before 'my $debug=...'.)

If it does, then the only remaining option is that $self->{UNLOADME}
*is* tied, and that the tied object is getting destroyed before its
parent. You can confirm this by changing the Devel::Peek::Dump line you
added before to

Devel::Peek::Dump($self->{UNLOADME});

If that output includes the MAGIC line I mentioned above, post it.

Ben

From: Ted Byers on
On May 20, 8:27 am, Ben Morrow <b...(a)morrow.me.uk> wrote:
> Quoth Ted Byers <r.ted.by...(a)gmail.com>:
>
>
>
> > On May 19, 6:54 pm, Ben Morrow <b...(a)morrow.me.uk> wrote:
> > > Quoth Ted Byers <r.ted.by...(a)gmail.com>:
>
> > > > Trace:
> > > > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/
> > > > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/
> > > > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485
> > > > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485
>
> > > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/
> > > > Win32/TieRegistry.pm line 1485, &#60;DATA&#62; line 335 during global
> > > > destruction.
>
> > > > Compilation finished at Wed May 19 16:41:23
>
> > > Am I correct that line 1485 of your copy of Win32/TieRegistry.pm is the
> > > last line here?
>
> > >     sub DESTROY
> > >     {
> > >         my $self= shift(@_);
> > >         return   if  tied(%$self);
> > >         my $unload;
> > >         eval { $unload= $self->{UNLOADME}; 1 }
>
> > > If so I can't see how that could be calling tie magic, since the code's
> > > just checked that it *isn't* tied. In any case, back up your copy of
> > > Win32/TieRegistry.pm and add
>
> > >     use Devel::Peek ();
> > >     use Carp ();
> > >     Devel::Peek::Dump($self);
> > >     Carp::confess("huh?");
>
> > > just before that line, and post the result.
>
> > I hadn't noticed that, but I was out of my depth as I have never used
> > the tie magic, and didn't know which of the packages I used would or
> > why.
>
> > In any event, here is the output after adding the four lines you
> > suggest:
>
> <snip>
> > SV = RV(0x22c15b0) at 0x22c15a4
> >   REFCNT = 1
> >   FLAGS = (PADMY,ROK)
> >   RV = 0x1c53074
> >   SV = PVHV(0x1e45c4c) at 0x1c53074
> >     REFCNT = 2
> >     FLAGS = (OBJECT,SHAREKEYS)
> >     STASH = 0x1f5b01c      "Win32::TieRegistry"
> >     ARRAY = 0x222f58c  (0:14, 1:14, 2:4)
> >     hash quality = 121.5%
> >     KEYS = 22
> >     FILL = 18
> >     MAX = 31
> >     RITER = -1
> >     EITER = 0x0
>
> OK, so the hash definitely isn't tied. (If it had been there would have
> been a whole MAGIC section, including the line
>
>     MG_TYPE = PERL_magic_tied(P)
>
> .)
>
> Can you confirm that the code does in fact get as far as l1485, and
> doesn't get any further? (Take out the 'confess', and put a 'warn'
> before 'eval { $unload=...' and another before 'my $debug=...'.)
>
> If it does, then the only remaining option is that $self->{UNLOADME}
> *is* tied, and that the tied object is getting destroyed before its
> parent. You can confirm this by changing the Devel::Peek::Dump line you
> added before to
>
>     Devel::Peek::Dump($self->{UNLOADME});
>
> If that output includes the MAGIC line I mentioned above, post it.
>
> Ben

Thanks Ben

Yes, it is confirmed that it gets to line 1485 and no further.

And changing the peek line as suggested produces the following:

SV = PVLV(0x185b6b4) at 0x22245bc
REFCNT = 1
FLAGS = (TEMP,GMG,SMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x243554c
MG_VIRTUAL = &PL_vtbl_defelem
MG_TYPE = PERL_MAGIC_defelem(y)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x22245cc
SV = PV(0x1fa55d4) at 0x22245cc
REFCNT = 1
FLAGS = (POK,pPOK)
PV = 0x1836474 "UNLOADME"\0
CUR = 8
LEN = 12
TYPE = y
TARGOFF = 0
TARGLEN = 1
TARG = 0x1bdb234
SV = PVHV(0x1e45c6c) at 0x1bdb234
REFCNT = 3
FLAGS = (OBJECT,SHAREKEYS)
STASH = 0x1f5b034 "Win32::TieRegistry"
ARRAY = 0x22298cc (0:14, 1:14, 2:4)
hash quality = 121.5%
KEYS = 22
FILL = 18
MAX = 31
RITER = -1
EITER = 0x0
Elt "CntValues" HASH = 0x359bb702
SV = IV(0x230a7a0) at 0x230a7a4
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 0
Elt "MaxSubClassLen" HASH = 0xb3d551a2
SV = IV(0x230a850) at 0x230a854
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 0
Elt "FLAGS" HASH = 0x1773e623
SV = IV(0x230a9b0) at 0x230a9b4
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 136


The "MG_TYPE = PERL_magic_tied(P)" isn't there. Instead, I see
"MG_TYPE = PERL_MAGIC_defelem(y)"

What next?

Would this be an issue with DBI, or the MySQL driver?

Is it likely to do any harm? The program runs fine otherwise. I am
just troubled that this error arises after the code I wrote finishes.
And seeing the name of the package where the error occurs is
"TieRegistry", I am concerned this error may introduce, or be a
consequence of, errors in my registry.

Thanks again

Ted

Thanks again,

Ted
From: Ted Byers on
On May 20, 8:27 am, Ben Morrow <b...(a)morrow.me.uk> wrote:
> Quoth Ted Byers <r.ted.by...(a)gmail.com>:
>
>
>
> > On May 19, 6:54 pm, Ben Morrow <b...(a)morrow.me.uk> wrote:
> > > Quoth Ted Byers <r.ted.by...(a)gmail.com>:
>
> > > > Trace:
> > > > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/
> > > > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/
> > > > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485
> > > > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485
>
> > > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/
> > > > Win32/TieRegistry.pm line 1485, &#60;DATA&#62; line 335 during global
> > > > destruction.
>
> > > > Compilation finished at Wed May 19 16:41:23
>
> > > Am I correct that line 1485 of your copy of Win32/TieRegistry.pm is the
> > > last line here?
>
> > >     sub DESTROY
> > >     {
> > >         my $self= shift(@_);
> > >         return   if  tied(%$self);
> > >         my $unload;
> > >         eval { $unload= $self->{UNLOADME}; 1 }
>
> > > If so I can't see how that could be calling tie magic, since the code's
> > > just checked that it *isn't* tied. In any case, back up your copy of
> > > Win32/TieRegistry.pm and add
>
> > >     use Devel::Peek ();
> > >     use Carp ();
> > >     Devel::Peek::Dump($self);
> > >     Carp::confess("huh?");
>
> > > just before that line, and post the result.
>
> > I hadn't noticed that, but I was out of my depth as I have never used
> > the tie magic, and didn't know which of the packages I used would or
> > why.
>
> > In any event, here is the output after adding the four lines you
> > suggest:
>
> <snip>
> > SV = RV(0x22c15b0) at 0x22c15a4
> >   REFCNT = 1
> >   FLAGS = (PADMY,ROK)
> >   RV = 0x1c53074
> >   SV = PVHV(0x1e45c4c) at 0x1c53074
> >     REFCNT = 2
> >     FLAGS = (OBJECT,SHAREKEYS)
> >     STASH = 0x1f5b01c      "Win32::TieRegistry"
> >     ARRAY = 0x222f58c  (0:14, 1:14, 2:4)
> >     hash quality = 121.5%
> >     KEYS = 22
> >     FILL = 18
> >     MAX = 31
> >     RITER = -1
> >     EITER = 0x0
>
> OK, so the hash definitely isn't tied. (If it had been there would have
> been a whole MAGIC section, including the line
>
>     MG_TYPE = PERL_magic_tied(P)
>
> .)
>
> Can you confirm that the code does in fact get as far as l1485, and
> doesn't get any further? (Take out the 'confess', and put a 'warn'
> before 'eval { $unload=...' and another before 'my $debug=...'.)
>
> If it does, then the only remaining option is that $self->{UNLOADME}
> *is* tied, and that the tied object is getting destroyed before its
> parent. You can confirm this by changing the Devel::Peek::Dump line you
> added before to
>
>     Devel::Peek::Dump($self->{UNLOADME});
>
> If that output includes the MAGIC line I mentioned above, post it.
>
> Ben

Thanks Ben

Yes, it is confirmed that it gets to line 1485 and no further.

And changing the peek line as suggested produces the following:

SV = PVLV(0x185b6b4) at 0x22245bc
REFCNT = 1
FLAGS = (TEMP,GMG,SMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x243554c
MG_VIRTUAL = &PL_vtbl_defelem
MG_TYPE = PERL_MAGIC_defelem(y)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x22245cc
SV = PV(0x1fa55d4) at 0x22245cc
REFCNT = 1
FLAGS = (POK,pPOK)
PV = 0x1836474 "UNLOADME"\0
CUR = 8
LEN = 12
TYPE = y
TARGOFF = 0
TARGLEN = 1
TARG = 0x1bdb234
SV = PVHV(0x1e45c6c) at 0x1bdb234
REFCNT = 3
FLAGS = (OBJECT,SHAREKEYS)
STASH = 0x1f5b034 "Win32::TieRegistry"
ARRAY = 0x22298cc (0:14, 1:14, 2:4)
hash quality = 121.5%
KEYS = 22
FILL = 18
MAX = 31
RITER = -1
EITER = 0x0
Elt "CntValues" HASH = 0x359bb702
SV = IV(0x230a7a0) at 0x230a7a4
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 0
Elt "MaxSubClassLen" HASH = 0xb3d551a2
SV = IV(0x230a850) at 0x230a854
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 0
Elt "FLAGS" HASH = 0x1773e623
SV = IV(0x230a9b0) at 0x230a9b4
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 136


The "MG_TYPE = PERL_magic_tied(P)" isn't there. Instead, I see
"MG_TYPE = PERL_MAGIC_defelem(y)"

What next?

Would this be an issue with DBI, or the MySQL driver?

Is it likely to do any harm? The program runs fine otherwise. I am
just troubled that this error arises after the code I wrote finishes.
And seeing the name of the package where the error occurs is
"TieRegistry", I am concerned this error may introduce, or be a
consequence of, errors in my registry.

Thanks again

Ted

Thanks again,

Ted
From: Ted Byers on
On May 20, 8:27 am, Ben Morrow <b...(a)morrow.me.uk> wrote:
> Quoth Ted Byers <r.ted.by...(a)gmail.com>:
>
>
>
> > On May 19, 6:54 pm, Ben Morrow <b...(a)morrow.me.uk> wrote:
> > > Quoth Ted Byers <r.ted.by...(a)gmail.com>:
>
> > > > Trace:
> > > > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/
> > > > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/
> > > > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485
> > > > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485
>
> > > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/
> > > > Win32/TieRegistry.pm line 1485, &#60;DATA&#62; line 335 during global
> > > > destruction.
>
> > > > Compilation finished at Wed May 19 16:41:23
>
> > > Am I correct that line 1485 of your copy of Win32/TieRegistry.pm is the
> > > last line here?
>
> > >     sub DESTROY
> > >     {
> > >         my $self= shift(@_);
> > >         return   if  tied(%$self);
> > >         my $unload;
> > >         eval { $unload= $self->{UNLOADME}; 1 }
>
> > > If so I can't see how that could be calling tie magic, since the code's
> > > just checked that it *isn't* tied. In any case, back up your copy of
> > > Win32/TieRegistry.pm and add
>
> > >     use Devel::Peek ();
> > >     use Carp ();
> > >     Devel::Peek::Dump($self);
> > >     Carp::confess("huh?");
>
> > > just before that line, and post the result.
>
> > I hadn't noticed that, but I was out of my depth as I have never used
> > the tie magic, and didn't know which of the packages I used would or
> > why.
>
> > In any event, here is the output after adding the four lines you
> > suggest:
>
> <snip>
> > SV = RV(0x22c15b0) at 0x22c15a4
> >   REFCNT = 1
> >   FLAGS = (PADMY,ROK)
> >   RV = 0x1c53074
> >   SV = PVHV(0x1e45c4c) at 0x1c53074
> >     REFCNT = 2
> >     FLAGS = (OBJECT,SHAREKEYS)
> >     STASH = 0x1f5b01c      "Win32::TieRegistry"
> >     ARRAY = 0x222f58c  (0:14, 1:14, 2:4)
> >     hash quality = 121.5%
> >     KEYS = 22
> >     FILL = 18
> >     MAX = 31
> >     RITER = -1
> >     EITER = 0x0
>
> OK, so the hash definitely isn't tied. (If it had been there would have
> been a whole MAGIC section, including the line
>
>     MG_TYPE = PERL_magic_tied(P)
>
> .)
>
> Can you confirm that the code does in fact get as far as l1485, and
> doesn't get any further? (Take out the 'confess', and put a 'warn'
> before 'eval { $unload=...' and another before 'my $debug=...'.)
>
> If it does, then the only remaining option is that $self->{UNLOADME}
> *is* tied, and that the tied object is getting destroyed before its
> parent. You can confirm this by changing the Devel::Peek::Dump line you
> added before to
>
>     Devel::Peek::Dump($self->{UNLOADME});
>
> If that output includes the MAGIC line I mentioned above, post it.
>
> Ben

Thanks Ben

Yes, it is confirmed that it gets to line 1485 and no further.

And changing the peek line as suggested produces the following:

SV = PVLV(0x185b6b4) at 0x22245bc
REFCNT = 1
FLAGS = (TEMP,GMG,SMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x243554c
MG_VIRTUAL = &PL_vtbl_defelem
MG_TYPE = PERL_MAGIC_defelem(y)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x22245cc
SV = PV(0x1fa55d4) at 0x22245cc
REFCNT = 1
FLAGS = (POK,pPOK)
PV = 0x1836474 "UNLOADME"\0
CUR = 8
LEN = 12
TYPE = y
TARGOFF = 0
TARGLEN = 1
TARG = 0x1bdb234
SV = PVHV(0x1e45c6c) at 0x1bdb234
REFCNT = 3
FLAGS = (OBJECT,SHAREKEYS)
STASH = 0x1f5b034 "Win32::TieRegistry"
ARRAY = 0x22298cc (0:14, 1:14, 2:4)
hash quality = 121.5%
KEYS = 22
FILL = 18
MAX = 31
RITER = -1
EITER = 0x0
Elt "CntValues" HASH = 0x359bb702
SV = IV(0x230a7a0) at 0x230a7a4
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 0
Elt "MaxSubClassLen" HASH = 0xb3d551a2
SV = IV(0x230a850) at 0x230a854
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 0
Elt "FLAGS" HASH = 0x1773e623
SV = IV(0x230a9b0) at 0x230a9b4
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 136


The "MG_TYPE = PERL_magic_tied(P)" isn't there. Instead, I see
"MG_TYPE = PERL_MAGIC_defelem(y)"

What next?

Would this be an issue with DBI, or the MySQL driver?

Is it likely to do any harm? The program runs fine otherwise. I am
just troubled that this error arises after the code I wrote finishes.
And seeing the name of the package where the error occurs is
"TieRegistry", I am concerned this error may introduce, or be a
consequence of, errors in my registry.

Thanks again

Ted

Thanks again,

Ted
From: Ted Byers on
On May 20, 10:33 am, Ted Byers <r.ted.by...(a)gmail.com> wrote:
> On May 20, 8:27 am, Ben Morrow <b...(a)morrow.me.uk> wrote:
>
>
>
> > Quoth Ted Byers <r.ted.by...(a)gmail.com>:
>
> > > On May 19, 6:54 pm, Ben Morrow <b...(a)morrow.me.uk> wrote:
> > > > Quoth Ted Byers <r.ted.by...(a)gmail.com>:
>
> > > > > Trace:
> > > > > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/
> > > > > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/
> > > > > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485
> > > > > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485
>
> > > > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/
> > > > > Win32/TieRegistry.pm line 1485, &#60;DATA&#62; line 335 during global
> > > > > destruction.
>
> > > > > Compilation finished at Wed May 19 16:41:23
>
> > > > Am I correct that line 1485 of your copy of Win32/TieRegistry.pm is the
> > > > last line here?
>
> > > >     sub DESTROY
> > > >     {
> > > >         my $self= shift(@_);
> > > >         return   if  tied(%$self);
> > > >         my $unload;
> > > >         eval { $unload= $self->{UNLOADME}; 1 }
>
> > > > If so I can't see how that could be calling tie magic, since the code's
> > > > just checked that it *isn't* tied. In any case, back up your copy of
> > > > Win32/TieRegistry.pm and add
>
> > > >     use Devel::Peek ();
> > > >     use Carp ();
> > > >     Devel::Peek::Dump($self);
> > > >     Carp::confess("huh?");
>
> > > > just before that line, and post the result.
>
> > > I hadn't noticed that, but I was out of my depth as I have never used
> > > the tie magic, and didn't know which of the packages I used would or
> > > why.
>
> > > In any event, here is the output after adding the four lines you
> > > suggest:
>
> > <snip>
> > > SV = RV(0x22c15b0) at 0x22c15a4
> > >   REFCNT = 1
> > >   FLAGS = (PADMY,ROK)
> > >   RV = 0x1c53074
> > >   SV = PVHV(0x1e45c4c) at 0x1c53074
> > >     REFCNT = 2
> > >     FLAGS = (OBJECT,SHAREKEYS)
> > >     STASH = 0x1f5b01c      "Win32::TieRegistry"
> > >     ARRAY = 0x222f58c  (0:14, 1:14, 2:4)
> > >     hash quality = 121.5%
> > >     KEYS = 22
> > >     FILL = 18
> > >     MAX = 31
> > >     RITER = -1
> > >     EITER = 0x0
>
> > OK, so the hash definitely isn't tied. (If it had been there would have
> > been a whole MAGIC section, including the line
>
> >     MG_TYPE = PERL_magic_tied(P)
>
> > .)
>
> > Can you confirm that the code does in fact get as far as l1485, and
> > doesn't get any further? (Take out the 'confess', and put a 'warn'
> > before 'eval { $unload=...' and another before 'my $debug=...'.)
>
> > If it does, then the only remaining option is that $self->{UNLOADME}
> > *is* tied, and that the tied object is getting destroyed before its
> > parent. You can confirm this by changing the Devel::Peek::Dump line you
> > added before to
>
> >     Devel::Peek::Dump($self->{UNLOADME});
>
> > If that output includes the MAGIC line I mentioned above, post it.
>
> > Ben
>
> Thanks Ben
>
> Yes, it is confirmed that it gets to line 1485 and no further.
>
> And changing the peek line as suggested produces the following:
>
> SV = PVLV(0x185b6b4) at 0x22245bc
>   REFCNT = 1
>   FLAGS = (TEMP,GMG,SMG)
>   IV = 0
>   NV = 0
>   PV = 0
>   MAGIC = 0x243554c
>     MG_VIRTUAL = &PL_vtbl_defelem
>     MG_TYPE = PERL_MAGIC_defelem(y)
>     MG_FLAGS = 0x02
>       REFCOUNTED
>     MG_OBJ = 0x22245cc
>     SV = PV(0x1fa55d4) at 0x22245cc
>       REFCNT = 1
>       FLAGS = (POK,pPOK)
>       PV = 0x1836474 "UNLOADME"\0
>       CUR = 8
>       LEN = 12
>   TYPE = y
>   TARGOFF = 0
>   TARGLEN = 1
>   TARG = 0x1bdb234
>   SV = PVHV(0x1e45c6c) at 0x1bdb234
>     REFCNT = 3
>     FLAGS = (OBJECT,SHAREKEYS)
>     STASH = 0x1f5b034   "Win32::TieRegistry"
>     ARRAY = 0x22298cc  (0:14, 1:14, 2:4)
>     hash quality = 121.5%
>     KEYS = 22
>     FILL = 18
>     MAX = 31
>     RITER = -1
>     EITER = 0x0
>     Elt "CntValues" HASH = 0x359bb702
>     SV = IV(0x230a7a0) at 0x230a7a4
>       REFCNT = 1
>       FLAGS = (IOK,pIOK)
>       IV = 0
>     Elt "MaxSubClassLen" HASH = 0xb3d551a2
>     SV = IV(0x230a850) at 0x230a854
>       REFCNT = 1
>       FLAGS = (IOK,pIOK)
>       IV = 0
>     Elt "FLAGS" HASH = 0x1773e623
>     SV = IV(0x230a9b0) at 0x230a9b4
>       REFCNT = 1
>       FLAGS = (IOK,pIOK)
>       IV = 136
>
> The "MG_TYPE = PERL_magic_tied(P)" isn't there.  Instead, I see
> "MG_TYPE = PERL_MAGIC_defelem(y)"
>
> What next?
>
> Would this be an issue with DBI, or the MySQL driver?
>
> Is it likely to do any harm?  The program runs fine otherwise.  I am
> just troubled that this error arises after the code I wrote finishes.
> And seeing the name of the package where the error occurs is
> "TieRegistry", I am concerned this error may introduce, or be a
> consequence of, errors in my registry.
>
> Thanks again
>
> Ted
>
> Thanks again,
>
> Ted

On a different note, any ideas why Google is sending my notes multiple
times to this forum? This is actuall the first time I have seen this
nuisance arise.

If it matters, I am using Firefox to access usenet via google/groups.
I have no other way to access this forum, or any other.