Debugging question: tracing the origin of an error.

[Ted Byers]

I have done all the usual things (as specified in the FAQ), and more,
but it isn't enough.

Here is how my script starts:

use strict;
use warnings;
use DBI;
use DateTime::Format::MySQL;
use Date::Manip;
use DateTime::Format:ateManip;

BEGIN {
$SIG{__WARN__} = sub{ print STDERR "Perl: ", @_; };
$SIG{__DIE__} = sub{ print STDERR "Perl: ", @_; exit 1};
}

$| = 1;

In the body of the script, this script does very little except make a
DB connection, place the values from the record set that results from
a trivial select query into a variable, and then prints it. Then all
handles are closed and the progrma ends. The error actually arises
after the last statement (and does not appear in ANY of my other
scripts that use the packes listed above).

Here is the error statement I get:

Perl: Can't call method "FETCH" on an undefined value at C:/Perl/site/
lib/Win32/TieRegistry.pm line 1485, <DATA> line 335 during global
destruction.

At no time have I made direct use of the file mentioned, so it must be
something one of the above packages has done. However, there is no
information provided as to what happened that led to this error. It
does not even say what object is being destructed or what package
created, or failed to create, it.

How can I modify the signal handling I set up above so that I can get
this information?

Thanks

Ted

 

[C.DeRykus]

I have done all the usual things (as specified in the FAQ), and more,
but it isn't enough.

Here is how my script starts:

use strict;
use warnings;
use DBI;
use DateTime::Format::MySQL;
use Date::Manip;
use DateTime::Format:ateManip;

BEGIN {
            $SIG{__WARN__} = sub{ print STDERR "Perl: ", @_; };
            $SIG{__DIE__}  = sub{ print STDERR "Perl: ", @_; exit 1};

}

$| = 1;

In the body of the script, this script does very little except make a
DB connection, place the values from the record set that results from
a trivial select query into a variable, and then prints it.  Then all
handles are closed and the progrma ends.  The error actually arises
after the last statement (and does not appear in ANY of my other
scripts that use the packes listed above).

Here is the error statement I get:

Perl: Can't call method "FETCH" on an undefined value at C:/Perl/site/
lib/Win32/TieRegistry.pm line 1485, <DATA> line 335 during global
destruction.

At no time have I made direct use of the file mentioned, so it must be
something one of the above packages has done.  However, there is no
information provided as to what happened that led to this error.  It
does not even say what object is being destructed or what package
created, or failed to create, it.

How can I modify the signal handling I set up above so that I can get
this information?

Here's an purported cure:

END { $^W = 0; }

 

[Ted Byers]

Here's an purported cure:

   END { $^W = 0; }

Thanks Charles.

Alas, the purported cure "END { $^W = 0; }" doesn't work in this
instance (unless I used it incorrectly). In any event, do you know
how that purported cure is supposed to work?

I am using ActiveSate's perl (v5.10.0) on Windows, and have examined
each of the tools I thought might have something useful, but either
they didn't have something that would answer my question or I didn't
understand the documentation.

Almost a decade ago, I wrote a C++ template class that I used to wrap
all exception classes and, using RTTI, I made exceptions traceable,
including not only the line and file of the source code where the
exception arose but also the class affected and all functions applied
to it from the time an instance of the class was created to the time
the exception was produced; and this in addition to a simple call
stack. This proved priceless in debugging my own code (and
identifying cases where I was hit by a bug in one or another of the
libraries I used, so I could focus on finding a work-around rather
than seeking a bug that didn't exist in my code). But, it was useful
only when I could compile it into my code which normally meant my own
code only. Alas, it relied on compiler specific macros in addition to
a couple of my own, and the language has changed since I did that.

Anyway, in addition to making this specific error go away, what I
really need is something I can include at the top of my script and
have it produce info about any object the script makes (whether
explicitly or indirectly as part of the internals of a package that
had been included), and what happens to it, but prints this info only
if that object is involved in an error: basically a perl equivalent of
the traceable exceptions I'd made in C++ so very long ago. I realize
Perl isn't C++, and that the specific method I'd used is probably not
viable in perl, but since both languages are Turing complete, anything
that is possible in one ought to be possible in the other.

So, then, what to do?

Thanks

Ted

 

[C.DeRykus]

Alas, the purported cure "END { $^W = 0; }" doesn't work in this
instance (unless I used it incorrectly).  In any event, do you know
how that purported cure is supposed to work?

I thought I recalled seeing the error/cure once before.
But, here's a thread that suggests just wrapping the
disconnect. Their error output is virtually the same:

{ $^W = 0; $dbh->disconnect }


perl case.pl
DBI::db=HASH(0x8f68e40) trace level set to 9 in
...
<- DESTROY= undef at unknown location!
(in cleanup) Can't call method "FETCH" on an
undefined value at
C:/opt/perl/site/lib/Win32/TieRegistry.pm
line 1486 during global destruction.

I am using ActiveSate's perl (v5.10.0) on Windows, and have examined
each of the tools I thought might have something useful, but either
they didn't have something that would answer my question or I didn't
understand the documentation.

Almost a decade ago, I wrote a C++ template class that I used to wrap
all exception classes and, using RTTI, I made exceptions traceable,
including not only the line and file of the source code where the
exception arose but also the class affected and all functions applied
to it from the time an instance of the class was created to the time
the exception was produced; and this in addition to a simple call
stack.  This proved priceless in debugging my own code (and
identifying cases where I was hit by a bug in one or another of the
libraries I used, so I could focus on finding a work-around rather
than seeking a bug that didn't exist in my code).  But, it was  useful
only when I could compile it into my code which normally meant my own
code only.  Alas, it relied on compiler specific macros in addition to
a couple of my own, and the language has changed since I did that.

Anyway, in addition to making this specific error go away, what I
really need is something I can include at the top of my script and
have it produce info about any object the script makes (whether
explicitly or indirectly as part of the internals of a package that
had been included), and what happens to it, but prints this info only
if that object is involved in an error: basically a perl equivalent of
the traceable exceptions I'd made in C++ so very long ago.  
...

If this new cure doesn't work, you might try one of DBI's
higher trace settings too as they demo in the thread.

 

[Steve M]

I have done all the usual things (as specified in the FAQ), and more,
but it isn't enough.

Here is how my script starts:

use strict;
use warnings;
use DBI;
use DateTime::Format::MySQL;
use Date::Manip;
use DateTime::Format:ateManip;

BEGIN {
$SIG{__WARN__} = sub{ print STDERR "Perl: ", @_; };
$SIG{__DIE__} = sub{ print STDERR "Perl: ", @_; exit 1};
}

$| = 1;

In the body of the script, this script does very little except make a
DB connection, place the values from the record set that results from
a trivial select query into a variable, and then prints it. Then all
handles are closed and the progrma ends. The error actually arises
after the last statement (and does not appear in ANY of my other
scripts that use the packes listed above).

Here is the error statement I get:

Perl: Can't call method "FETCH" on an undefined value at C:/Perl/site/
lib/Win32/TieRegistry.pm line 1485,<DATA> line 335 during global
destruction.

At no time have I made direct use of the file mentioned, so it must be
something one of the above packages has done. However, there is no
information provided as to what happened that led to this error. It
does not even say what object is being destructed or what package
created, or failed to create, it.

How can I modify the signal handling I set up above so that I can get
this information?

Thanks

Ted

I use the below to trace down this sort of thing.. Posted it in response
to something else (CGI related) a few weeks ago and no one pointed out
any obvious no-no's so it was either more or less acceptable or else was
thought so stupid is was ignored.

Anyway, the meat of the thing uses Perl's caller function and it
iterates back through stack frames recording a trace. Very useful at
times and may help you determine what is going on...

I DID fiddle this a little bit to run from command line (html stuff
removed) so it might have a syntax error, though it doesn't look like it...

# a different approach to trapping errors.....
# screws up eval used as an error trap
$SIG{'__DIE__'} = $SIG{'__WARN__'} = sub {
my $error = shift;
chomp $error;
$error =~ s/[<&>]/"&#".ord($&).";"/ge; # entity escape;
$error = &Caller_error_path( $error,1,0 );
print "$error\n";
exit 0;
};

sub Caller_error_path {
my $error = shift;
my $Shift = shift;
my $Pop = shift;
$error ||= '';

my $i = 0;
my @call_list = ();
while( my($p, $f, $l, $s, $h, $w ) = caller($i++) ){
my $string = '';
$f and $string .= "$f, ";
$l and $string .= "Line: $l\n";
$s and $s !~ /main::__ANON__/ and $string .= "$s, ";
push @call_list, $string;
}

$Shift and shift @call_list;
$Pop and pop @call_list;

@call_list = reverse @call_list;

my $path = "\nTrace:\n";
$path .= join '', @call_list;
return "$path\n$error";

}


hth,

\s

 

[Steve M]

You should lose that ampersand.


perldoc -q function

What's the difference between calling a function as&foo and foo()?

Hmmmm... Well, I got a comment.

Bear with me being a little thick here, as I'm not sure I see a
functional problem with the way I'm doing it.

First, I admit that my understanding of prototypes is not as strong as
it might be since I rarely fiddle with them.

Nevertheless, my understanding is/was that using the '&' makes no
difference except for passing the current @_ which makes no difference
(as far as I can tell) if the called function does not address it's own
@_ in any way.

The docs referenced seem to say the same thing (to me).
They show an example demonstrating the differing behavior, explain a
usage for the behavior, but do not indicate one should not make a call
as I have done above.

In the code referenced above, I *am* passing arguments and the docs (and
Programming Perl) seem to say I'm correct in thinking '&' or not makes
no difference in that case. Am I????

If the called function performed based on the existence of passed
value(s), then I can see the point of worrying about it. On the other
hand I would hope I'd know what a subroutine I was calling did, and I am
aware of the issue, so.....

In short, is this a style/usage thing? Or am I totally missing some
other potential problem?



TIA,



\s

 

[Steve M]

It's mostly a style/usage thing. The biggest potential problem is that
the& calls ignore prototypes; a smaller (but IMHO just as important)
problem is that the& asks for a rather specific and rarely-wanted
feature that you don't need in this case, so anyone reading that code
has to think 'Why is that& there? Why does this call need to override
prototypes?'.

Ben

OK, I guess I can see that.

I was aware of the pass through issue(s), but wrote that way anyway
because it makes/made it easier for me to visually scan the code for
subroutine calls. And I wasn't real concerned about the prototype issues
since I don't use that approach. But if it makes things confusing for
the next poor sod who comes along.... well, I'm not planning on living
forever.

Thanks guys, you've given me something to think about.

\s

 

[Ted Byers]

I thought I recalled seeing the error/cure once before.
But, here's a thread that suggests just wrapping the
disconnect. Their error output is virtually the same:

{ $^W = 0; $dbh->disconnect }

  perl case.pl
         DBI::db=HASH(0x8f68e40) trace level set to 9 in
         ...
          <- DESTROY= undef at unknown location!
          (in cleanup) Can't call method "FETCH" on an
           undefined value at
            C:/opt/perl/site/lib/Win32/TieRegistry.pm
            line 1486 during global destruction.








If this new cure doesn't work, you might try one of DBI's
higher trace settings too as they demo in the thread.

OK, Combining Steve's suggestion (with teh suggested ammendment
regarding '&, with yours, at trace level 10, I get the following
output AFTER all my source code has been executed correctly:
ima10004 pid#18652)
ima10004 pid#18652)
-> DESTROY for DBD::mysql::st (DBI::st=HASH(0x2e48dcc)~INNER)
thr#3424c
<- DESTROY= undef
DESTROY (dbih_clearcom) (sth 0x2e48dcc, com 0x24459b4, imp
DBD::mysql::st):
FLAGS 0x180191: COMSET Warn RaiseError PrintError PrintWarn
PARENT DBI::db=HASH(0x242e7ec)
KIDS 0 (0 Active)
NUM_OF_FIELDS 5
NUM_OF_PARAMS 0
dbih_clearcom 0x2e48dcc (com 0x24459b4, type 3) done.
ima10004 pid#18652)
ima10004 pid#18652)
-> DESTROY for DBD::mysql::db (DBI::db=HASH(0x242e7ec)~INNER)
thr#3424c
imp_dbh->pmysql: 242864c
<- DESTROY= undef
DESTROY (dbih_clearcom) (dbh 0x242e7ec, com 0x245a44c, imp
DBD::mysql::db):
FLAGS 0x180391: COMSET Warn RaiseError PrintError PrintWarn
AutoCommit
PARENT DBI::dr=HASH(0x242ec9c)
KIDS 0 (0 Active)
IMP_DATA HASH(0x242e78c)
dbih_clearcom 0x242e7ec (com 0x245a44c, type 2) done.

-- DBI::END ($@: , $!: )ima801 pid#18652) at C:/Perl/site/lib/DBI.pm line 731 via at k:/
Projects/NewRiskModel/Simple.Risk.Model.pl line 0
-> disconnect_all for DBD::mysql::dr
(DBI::dr=HASH(0x24066d4)~0x242ec9c) thr#3424c
<- disconnect_all= (not implemented) at C:/Perl/site/lib/DBI.pm
line 731 via at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0
! >> DESTROY DISPATCH (DBI::dr=HASH(0x24066d4) rc1/1 @1 g0
ima10004 pid#18652) during global destruction
! <> DESTROY(DBI::dr=HASH(0x24066d4)) ignored for outer handle
(inner DBI::dr=HASH(0x242ec9c) has ref cnt 1)
! >> DESTROY DISPATCH (DBI::dr=HASH(0x242ec9c) rc1/1 @1 g0
ima10004 pid#18652) during global destruction
! -> DESTROY in DBD::_::common for DBD::mysql::dr
(DBI::dr=HASH(0x242ec9c)~INNER) thr#3424c
! <- DESTROY= undef during global destruction
DESTROY (dbih_clearcom) (drh 0x242ec9c, com 0x23f95d4, imp global
destruction):
FLAGS 0x100215: COMSET Active Warn PrintWarn AutoCommit
PARENT undef
KIDS 0 (0 Active)
dbih_clearcom 0x242ec9c (com 0x23f95d4, type 1) done.


Trace:
k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/
NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry:ESTROY, 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, <DATA> line 335 during global
destruction.

Compilation finished at Wed May 19 16:41:23


Correct me if I am wrong, it looks like DBI is disconnecting/
destroying children recursively up through their parents, until
everything is destroyed, and then the error happens. It still isn't
clear what object it is trying to call fetch on. I will continue
trying with still higher trace levels, but I am baffled why this hits
here but not in my other scripts that use DBI. It doesn't seem to
matter if I call $dbh->disconnect(), though my inclination is to call
it once I have all the data I need to process.

Any other ideas about why this happens and how best to address it?

Thanks

Ted

 

[Ted Byers]

I thought I recalled seeing the error/cure once before.
But, here's a thread that suggests just wrapping the
disconnect. Their error output is virtually the same:

{ $^W = 0; $dbh->disconnect }

  perl case.pl
         DBI::db=HASH(0x8f68e40) trace level set to 9 in
         ...
          <- DESTROY= undef at unknown location!
          (in cleanup) Can't call method "FETCH" on an
           undefined value at
            C:/opt/perl/site/lib/Win32/TieRegistry.pm
            line 1486 during global destruction.








If this new cure doesn't work, you might try one of DBI's
higher trace settings too as they demo in the thread.

OK, Combining Steve's suggestion (with teh suggested ammendment
regarding '&, with yours, at trace level 10, I get the following
output AFTER all my source code has been executed correctly:
ima10004 pid#18652)
ima10004 pid#18652)
-> DESTROY for DBD::mysql::st (DBI::st=HASH(0x2e48dcc)~INNER)
thr#3424c
<- DESTROY= undef
DESTROY (dbih_clearcom) (sth 0x2e48dcc, com 0x24459b4, imp
DBD::mysql::st):
FLAGS 0x180191: COMSET Warn RaiseError PrintError PrintWarn
PARENT DBI::db=HASH(0x242e7ec)
KIDS 0 (0 Active)
NUM_OF_FIELDS 5
NUM_OF_PARAMS 0
dbih_clearcom 0x2e48dcc (com 0x24459b4, type 3) done.
ima10004 pid#18652)
ima10004 pid#18652)
-> DESTROY for DBD::mysql::db (DBI::db=HASH(0x242e7ec)~INNER)
thr#3424c
imp_dbh->pmysql: 242864c
<- DESTROY= undef
DESTROY (dbih_clearcom) (dbh 0x242e7ec, com 0x245a44c, imp
DBD::mysql::db):
FLAGS 0x180391: COMSET Warn RaiseError PrintError PrintWarn
AutoCommit
PARENT DBI::dr=HASH(0x242ec9c)
KIDS 0 (0 Active)
IMP_DATA HASH(0x242e78c)
dbih_clearcom 0x242e7ec (com 0x245a44c, type 2) done.

-- DBI::END ($@: , $!: )ima801 pid#18652) at C:/Perl/site/lib/DBI.pm line 731 via at k:/
Projects/NewRiskModel/Simple.Risk.Model.pl line 0
-> disconnect_all for DBD::mysql::dr
(DBI::dr=HASH(0x24066d4)~0x242ec9c) thr#3424c
<- disconnect_all= (not implemented) at C:/Perl/site/lib/DBI.pm
line 731 via at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0
! >> DESTROY DISPATCH (DBI::dr=HASH(0x24066d4) rc1/1 @1 g0
ima10004 pid#18652) during global destruction
! <> DESTROY(DBI::dr=HASH(0x24066d4)) ignored for outer handle
(inner DBI::dr=HASH(0x242ec9c) has ref cnt 1)
! >> DESTROY DISPATCH (DBI::dr=HASH(0x242ec9c) rc1/1 @1 g0
ima10004 pid#18652) during global destruction
! -> DESTROY in DBD::_::common for DBD::mysql::dr
(DBI::dr=HASH(0x242ec9c)~INNER) thr#3424c
! <- DESTROY= undef during global destruction
DESTROY (dbih_clearcom) (drh 0x242ec9c, com 0x23f95d4, imp global
destruction):
FLAGS 0x100215: COMSET Active Warn PrintWarn AutoCommit
PARENT undef
KIDS 0 (0 Active)
dbih_clearcom 0x242ec9c (com 0x23f95d4, type 1) done.


Trace:
k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/
NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry:ESTROY, 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, <DATA> line 335 during global
destruction.

Compilation finished at Wed May 19 16:41:23


Correct me if I am wrong, it looks like DBI is disconnecting/
destroying children recursively up through their parents, until
everything is destroyed, and then the error happens. It still isn't
clear what object it is trying to call fetch on. I will continue
trying with still higher trace levels, but I am baffled why this hits
here but not in my other scripts that use DBI. It doesn't seem to
matter if I call $dbh->disconnect(), though my inclination is to call
it once I have all the data I need to process.

Any other ideas about why this happens and how best to address it?

Thanks

Ted

 

[Ted Byers]

I thought I recalled seeing the error/cure once before.
But, here's a thread that suggests just wrapping the
disconnect. Their error output is virtually the same:

{ $^W = 0; $dbh->disconnect }

  perl case.pl
         DBI::db=HASH(0x8f68e40) trace level set to 9 in
         ...
          <- DESTROY= undef at unknown location!
          (in cleanup) Can't call method "FETCH" on an
           undefined value at
            C:/opt/perl/site/lib/Win32/TieRegistry.pm
            line 1486 during global destruction.








If this new cure doesn't work, you might try one of DBI's
higher trace settings too as they demo in the thread.

OK, Combining Steve's suggestion (with teh suggested ammendment
regarding '&, with yours, at trace level 10, I get the following
output AFTER all my source code has been executed correctly:
ima10004 pid#18652)
ima10004 pid#18652)
-> DESTROY for DBD::mysql::st (DBI::st=HASH(0x2e48dcc)~INNER)
thr#3424c
<- DESTROY= undef
DESTROY (dbih_clearcom) (sth 0x2e48dcc, com 0x24459b4, imp
DBD::mysql::st):
FLAGS 0x180191: COMSET Warn RaiseError PrintError PrintWarn
PARENT DBI::db=HASH(0x242e7ec)
KIDS 0 (0 Active)
NUM_OF_FIELDS 5
NUM_OF_PARAMS 0
dbih_clearcom 0x2e48dcc (com 0x24459b4, type 3) done.
ima10004 pid#18652)
ima10004 pid#18652)
-> DESTROY for DBD::mysql::db (DBI::db=HASH(0x242e7ec)~INNER)
thr#3424c
imp_dbh->pmysql: 242864c
<- DESTROY= undef
DESTROY (dbih_clearcom) (dbh 0x242e7ec, com 0x245a44c, imp
DBD::mysql::db):
FLAGS 0x180391: COMSET Warn RaiseError PrintError PrintWarn
AutoCommit
PARENT DBI::dr=HASH(0x242ec9c)
KIDS 0 (0 Active)
IMP_DATA HASH(0x242e78c)
dbih_clearcom 0x242e7ec (com 0x245a44c, type 2) done.

-- DBI::END ($@: , $!: )ima801 pid#18652) at C:/Perl/site/lib/DBI.pm line 731 via at k:/
Projects/NewRiskModel/Simple.Risk.Model.pl line 0
-> disconnect_all for DBD::mysql::dr
(DBI::dr=HASH(0x24066d4)~0x242ec9c) thr#3424c
<- disconnect_all= (not implemented) at C:/Perl/site/lib/DBI.pm
line 731 via at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0
! >> DESTROY DISPATCH (DBI::dr=HASH(0x24066d4) rc1/1 @1 g0
ima10004 pid#18652) during global destruction
! <> DESTROY(DBI::dr=HASH(0x24066d4)) ignored for outer handle
(inner DBI::dr=HASH(0x242ec9c) has ref cnt 1)
! >> DESTROY DISPATCH (DBI::dr=HASH(0x242ec9c) rc1/1 @1 g0
ima10004 pid#18652) during global destruction
! -> DESTROY in DBD::_::common for DBD::mysql::dr
(DBI::dr=HASH(0x242ec9c)~INNER) thr#3424c
! <- DESTROY= undef during global destruction
DESTROY (dbih_clearcom) (drh 0x242ec9c, com 0x23f95d4, imp global
destruction):
FLAGS 0x100215: COMSET Active Warn PrintWarn AutoCommit
PARENT undef
KIDS 0 (0 Active)
dbih_clearcom 0x242ec9c (com 0x23f95d4, type 1) done.


Trace:
k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/
NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry:ESTROY, 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, <DATA> line 335 during global
destruction.

Compilation finished at Wed May 19 16:41:23


Correct me if I am wrong, it looks like DBI is disconnecting/
destroying children recursively up through their parents, until
everything is destroyed, and then the error happens. It still isn't
clear what object it is trying to call fetch on. I will continue
trying with still higher trace levels, but I am baffled why this hits
here but not in my other scripts that use DBI. It doesn't seem to
matter if I call $dbh->disconnect(), though my inclination is to call
it once I have all the data I need to process.

Any other ideas about why this happens and how best to address it?

Thanks

Ted

 

[sln]

Correct me if I am wrong, it looks like DBI is disconnecting/
destroying children recursively up through their parents, until
everything is destroyed, and then the error happens. It still isn't
clear what object it is trying to call fetch on. I will continue
trying with still higher trace levels, but I am baffled why this hits
here but not in my other scripts that use DBI. It doesn't seem to
matter if I call $dbh->disconnect(), though my inclination is to call
it once I have all the data I need to process.

Any other ideas about why this happens and how best to address it?

No but, your googlegroups.com is tripple posting this to usenet.

-sln

 

[Ted Byers]

OK, Combining Steve's suggestion (with teh suggested ammendment
regarding '&, with yours, at trace level 10, I get the following
output AFTER all my source code has been executed correctly:

    >> DESTROY     DISPATCH (DBI::st=HASH(0x242e39c) rc1/1 @1 g0
ima10004 pid#18652)
    <> DESTROY(DBI::st=HASH(0x242e39c)) ignored for outer handle
(inner DBI::st=HASH(0x2e48dcc) has ref cnt 1)
    >> DESTROY     DISPATCH (DBI::st=HASH(0x2e48dcc) rc1/1 @1 g0
ima10004 pid#18652)
    -> DESTROY for DBD::mysql::st (DBI::st=HASH(0x2e48dcc)~INNER)
thr#3424c
    <- DESTROY= undef
    DESTROY (dbih_clearcom) (sth 0x2e48dcc, com 0x24459b4, imp
DBD::mysql::st):
       FLAGS 0x180191: COMSET Warn RaiseError PrintError PrintWarn
       PARENT DBI::db=HASH(0x242e7ec)
       KIDS 0 (0 Active)
       NUM_OF_FIELDS 5
       NUM_OF_PARAMS 0
    dbih_clearcom 0x2e48dcc (com 0x24459b4, type 3) done.

    >> DESTROY     DISPATCH (DBI::db=HASH(0x242e6ac) rc1/1 @1 g0
ima10004 pid#18652)
    <> DESTROY(DBI::db=HASH(0x242e6ac)) ignored for outer handle
(inner DBI::db=HASH(0x242e7ec) has ref cnt 1)
    >> DESTROY     DISPATCH (DBI::db=HASH(0x242e7ec) rc1/1 @1 g0
ima10004 pid#18652)
    -> DESTROY for DBD::mysql::db (DBI::db=HASH(0x242e7ec)~INNER)
thr#3424c
imp_dbh->pmysql: 242864c
    <- DESTROY= undef
    DESTROY (dbih_clearcom) (dbh 0x242e7ec, com 0x245a44c, imp
DBD::mysql::db):
       FLAGS 0x180391: COMSET Warn RaiseError PrintError PrintWarn
AutoCommit
       PARENT DBI::dr=HASH(0x242ec9c)
       KIDS 0 (0 Active)
       IMP_DATA HASH(0x242e78c)
    dbih_clearcom 0x242e7ec (com 0x245a44c, type 2) done.

    -- DBI::END ($@: , $!: )
    >> disconnect_all DISPATCH (DBI::dr=HASH(0x24066d4) rc1/3 @1 g0
ima801 pid#18652) at C:/Perl/site/lib/DBI.pm line 731 via  at k:/
Projects/NewRiskModel/Simple.Risk.Model.pl line 0
    -> disconnect_all for DBD::mysql::dr
(DBI::dr=HASH(0x24066d4)~0x242ec9c) thr#3424c
    <- disconnect_all= (not implemented) at C:/Perl/site/lib/DBI.pm
line 731 via  at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0
!   >> DESTROY     DISPATCH (DBI::dr=HASH(0x24066d4) rc1/1 @1 g0
ima10004 pid#18652) during global destruction
!   <> DESTROY(DBI::dr=HASH(0x24066d4)) ignored for outer handle
(inner DBI::dr=HASH(0x242ec9c) has ref cnt 1)
!   >> DESTROY     DISPATCH (DBI::dr=HASH(0x242ec9c) rc1/1 @1 g0
ima10004 pid#18652) during global destruction
!   -> DESTROY in DBD::_::common for DBD::mysql::dr
(DBI::dr=HASH(0x242ec9c)~INNER) thr#3424c
!   <- DESTROY= undef during global destruction
    DESTROY (dbih_clearcom) (drh 0x242ec9c, com 0x23f95d4, imp global
destruction):
       FLAGS 0x100215: COMSET Active Warn PrintWarn AutoCommit
       PARENT undef
       KIDS 0 (0 Active)
    dbih_clearcom 0x242ec9c (com 0x23f95d4, type 1) done.

Trace:
k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/
NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry:ESTROY, 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, <DATA> line 335 during global
destruction.

Compilation finished at Wed May 19 16:41:23

Correct me if I am wrong, it looks like DBI is disconnecting/
destroying children recursively up through their parents, until
everything is destroyed, and then the error happens.  It still isn't
clear what object it is trying to call fetch on.  I will continue
trying with still higher trace levels, but I am baffled why this hits
here but not in my other scripts that use DBI.  It doesn't seem to
matter if I call $dbh->disconnect(), though my inclination is to call
it once I have all the data I need to process.

Any other ideas about why this happens and how best to address it?

Thanks

Ted

Just an update, the trae output does not change even if I go up to the
highest trace level.

 

[Ted Byers]

OK, Combining Steve's suggestion (with teh suggested ammendment
regarding '&, with yours, at trace level 10, I get the following
output AFTER all my source code has been executed correctly:

    >> DESTROY     DISPATCH (DBI::st=HASH(0x242e39c) rc1/1 @1 g0
ima10004 pid#18652)
    <> DESTROY(DBI::st=HASH(0x242e39c)) ignored for outer handle
(inner DBI::st=HASH(0x2e48dcc) has ref cnt 1)
    >> DESTROY     DISPATCH (DBI::st=HASH(0x2e48dcc) rc1/1 @1 g0
ima10004 pid#18652)
    -> DESTROY for DBD::mysql::st (DBI::st=HASH(0x2e48dcc)~INNER)
thr#3424c
    <- DESTROY= undef
    DESTROY (dbih_clearcom) (sth 0x2e48dcc, com 0x24459b4, imp
DBD::mysql::st):
       FLAGS 0x180191: COMSET Warn RaiseError PrintError PrintWarn
       PARENT DBI::db=HASH(0x242e7ec)
       KIDS 0 (0 Active)
       NUM_OF_FIELDS 5
       NUM_OF_PARAMS 0
    dbih_clearcom 0x2e48dcc (com 0x24459b4, type 3) done.

    >> DESTROY     DISPATCH (DBI::db=HASH(0x242e6ac) rc1/1 @1 g0
ima10004 pid#18652)
    <> DESTROY(DBI::db=HASH(0x242e6ac)) ignored for outer handle
(inner DBI::db=HASH(0x242e7ec) has ref cnt 1)
    >> DESTROY     DISPATCH (DBI::db=HASH(0x242e7ec) rc1/1 @1 g0
ima10004 pid#18652)
    -> DESTROY for DBD::mysql::db (DBI::db=HASH(0x242e7ec)~INNER)
thr#3424c
imp_dbh->pmysql: 242864c
    <- DESTROY= undef
    DESTROY (dbih_clearcom) (dbh 0x242e7ec, com 0x245a44c, imp
DBD::mysql::db):
       FLAGS 0x180391: COMSET Warn RaiseError PrintError PrintWarn
AutoCommit
       PARENT DBI::dr=HASH(0x242ec9c)
       KIDS 0 (0 Active)
       IMP_DATA HASH(0x242e78c)
    dbih_clearcom 0x242e7ec (com 0x245a44c, type 2) done.

    -- DBI::END ($@: , $!: )
    >> disconnect_all DISPATCH (DBI::dr=HASH(0x24066d4) rc1/3 @1 g0
ima801 pid#18652) at C:/Perl/site/lib/DBI.pm line 731 via  at k:/
Projects/NewRiskModel/Simple.Risk.Model.pl line 0
    -> disconnect_all for DBD::mysql::dr
(DBI::dr=HASH(0x24066d4)~0x242ec9c) thr#3424c
    <- disconnect_all= (not implemented) at C:/Perl/site/lib/DBI.pm
line 731 via  at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0
!   >> DESTROY     DISPATCH (DBI::dr=HASH(0x24066d4) rc1/1 @1 g0
ima10004 pid#18652) during global destruction
!   <> DESTROY(DBI::dr=HASH(0x24066d4)) ignored for outer handle
(inner DBI::dr=HASH(0x242ec9c) has ref cnt 1)
!   >> DESTROY     DISPATCH (DBI::dr=HASH(0x242ec9c) rc1/1 @1 g0
ima10004 pid#18652) during global destruction
!   -> DESTROY in DBD::_::common for DBD::mysql::dr
(DBI::dr=HASH(0x242ec9c)~INNER) thr#3424c
!   <- DESTROY= undef during global destruction
    DESTROY (dbih_clearcom) (drh 0x242ec9c, com 0x23f95d4, imp global
destruction):
       FLAGS 0x100215: COMSET Active Warn PrintWarn AutoCommit
       PARENT undef
       KIDS 0 (0 Active)
    dbih_clearcom 0x242ec9c (com 0x23f95d4, type 1) done.

Trace:
k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/
NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry:ESTROY, 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, <DATA> line 335 during global
destruction.

Compilation finished at Wed May 19 16:41:23

Correct me if I am wrong, it looks like DBI is disconnecting/
destroying children recursively up through their parents, until
everything is destroyed, and then the error happens.  It still isn't
clear what object it is trying to call fetch on.  I will continue
trying with still higher trace levels, but I am baffled why this hits
here but not in my other scripts that use DBI.  It doesn't seem to
matter if I call $dbh->disconnect(), though my inclination is to call
it once I have all the data I need to process.

Any other ideas about why this happens and how best to address it?

Thanks

Ted

Just an update, the trae output does not change even if I go up to the
highest trace level.

 

[Ted Byers]

Quoth Ted Byers <[email protected]>:






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:eek ();
    use Carp ();
    Devel:eek:ump($self);
    Carp::confess("huh?");

just before that line, and post the result.

Ben

Thanks Ben,

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:
ima10c01 pid#29840) at k:/Projects/NewRiskModel/Simple.Risk.Model.pl
line 228
-> disconnect for DBD::mysql::db
(DBI::db=HASH(0x244bc3c)~0x244bd7c) thr#3424c
imp_dbh->pmysql: 244f314
<- disconnect= 1 at k:/Projects/NewRiskModel/Simple.Risk.Model.pl
line 228ima10004 pid#29840)
ima10004 pid#29840)
-> DESTROY for DBD::mysql::st (DBI::st=HASH(0x2e95e3c)~INNER)
thr#3424c
<- DESTROY= undef
DESTROY (dbih_clearcom) (sth 0x2e95e3c, com 0x2476014, imp
DBD::mysql::st):
FLAGS 0x180191: COMSET Warn RaiseError PrintError PrintWarn
PARENT DBI::db=HASH(0x244bd7c)
KIDS 0 (0 Active)
NUM_OF_FIELDS 5
NUM_OF_PARAMS 0
dbih_clearcom 0x2e95e3c (com 0x2476014, type 3) done.
ima10004 pid#29840)
ima10004 pid#29840)
-> DESTROY for DBD::mysql::db (DBI::db=HASH(0x244bd7c)~INNER)
thr#3424c
<- DESTROY= undef
DESTROY (dbih_clearcom) (dbh 0x244bd7c, com 0x247e3b4, imp
DBD::mysql::db):
FLAGS 0x180391: COMSET Warn RaiseError PrintError PrintWarn
AutoCommit
PARENT DBI::dr=HASH(0x245a424)
KIDS 0 (0 Active)
IMP_DATA HASH(0x244bd1c)
dbih_clearcom 0x244bd7c (com 0x247e3b4, type 2) done.

-- DBI::END ($@: , $!: )ima801 pid#29840) at C:/Perl/site/lib/DBI.pm line 731 via at k:/
Projects/NewRiskModel/Simple.Risk.Model.pl line 0
-> disconnect_all for DBD::mysql::dr
(DBI::dr=HASH(0x2428bdc)~0x245a424) thr#3424c
<- disconnect_all= (not implemented) at C:/Perl/site/lib/DBI.pm
line 731 via at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0
! >> DESTROY DISPATCH (DBI::dr=HASH(0x2428bdc) rc1/1 @1 g0
ima10004 pid#29840) during global destruction
! <> DESTROY(DBI::dr=HASH(0x2428bdc)) ignored for outer handle
(inner DBI::dr=HASH(0x245a424) has ref cnt 1)
! >> DESTROY DISPATCH (DBI::dr=HASH(0x245a424) rc1/1 @1 g0
ima10004 pid#29840) during global destruction
! -> DESTROY in DBD::_::common for DBD::mysql::dr
(DBI::dr=HASH(0x245a424)~INNER) thr#3424c
! <- DESTROY= undef during global destruction
DESTROY (dbih_clearcom) (drh 0x245a424, com 0x1836ffc, imp global
destruction):
FLAGS 0x100215: COMSET Active Warn PrintWarn AutoCommit
PARENT undef
KIDS 0 (0 Active)
dbih_clearcom 0x245a424 (com 0x1836ffc, type 1) done.

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
Elt "CntValues" HASH = 0x359bb702
SV = IV(0x230a7b0) at 0x230a7b4
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 0
Elt "MaxSubClassLen" HASH = 0xb3d551a2
SV = IV(0x230a860) at 0x230a864
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 0
Elt "FLAGS" HASH = 0x1773e623
SV = IV(0x230a9c0) at 0x230a9c4
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 136

Trace:
k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/
NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry:ESTROY, C:/
Perl/site/lib/Win32/TieRegistry.pm, Line: 1488
Carp::confess, C:/Perl/lib/Carp.pm, Line: 45

huh? at C:/Perl/site/lib/Win32/TieRegistry.pm line 1488
Win32::TieRegistry:ESTROY('Win32::TieRegistry=HASH(0x1c53074)')
called at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0
eval {...} called at k:/Projects/NewRiskModel/Simple.Risk.Model.pl
line 0

Compilation finished at Wed May 19 20:59:57


Adding your four lines seems to have added the lines beginning with SV
= RV(0x22c15b0) at 0x22c15a4, but none of that info means anything to
me.

Any light that can be shed on this would be appreciated.

Thanks

Ted

 

[Ted Byers]

Quoth Ted Byers <[email protected]>:






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:eek ();
    use Carp ();
    Devel:eek:ump($self);
    Carp::confess("huh?");

just before that line, and post the result.

Ben

Thanks Ben,

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:
ima10c01 pid#29840) at k:/Projects/NewRiskModel/Simple.Risk.Model.pl
line 228
-> disconnect for DBD::mysql::db
(DBI::db=HASH(0x244bc3c)~0x244bd7c) thr#3424c
imp_dbh->pmysql: 244f314
<- disconnect= 1 at k:/Projects/NewRiskModel/Simple.Risk.Model.pl
line 228ima10004 pid#29840)
ima10004 pid#29840)
-> DESTROY for DBD::mysql::st (DBI::st=HASH(0x2e95e3c)~INNER)
thr#3424c
<- DESTROY= undef
DESTROY (dbih_clearcom) (sth 0x2e95e3c, com 0x2476014, imp
DBD::mysql::st):
FLAGS 0x180191: COMSET Warn RaiseError PrintError PrintWarn
PARENT DBI::db=HASH(0x244bd7c)
KIDS 0 (0 Active)
NUM_OF_FIELDS 5
NUM_OF_PARAMS 0
dbih_clearcom 0x2e95e3c (com 0x2476014, type 3) done.
ima10004 pid#29840)
ima10004 pid#29840)
-> DESTROY for DBD::mysql::db (DBI::db=HASH(0x244bd7c)~INNER)
thr#3424c
<- DESTROY= undef
DESTROY (dbih_clearcom) (dbh 0x244bd7c, com 0x247e3b4, imp
DBD::mysql::db):
FLAGS 0x180391: COMSET Warn RaiseError PrintError PrintWarn
AutoCommit
PARENT DBI::dr=HASH(0x245a424)
KIDS 0 (0 Active)
IMP_DATA HASH(0x244bd1c)
dbih_clearcom 0x244bd7c (com 0x247e3b4, type 2) done.

-- DBI::END ($@: , $!: )ima801 pid#29840) at C:/Perl/site/lib/DBI.pm line 731 via at k:/
Projects/NewRiskModel/Simple.Risk.Model.pl line 0
-> disconnect_all for DBD::mysql::dr
(DBI::dr=HASH(0x2428bdc)~0x245a424) thr#3424c
<- disconnect_all= (not implemented) at C:/Perl/site/lib/DBI.pm
line 731 via at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0
! >> DESTROY DISPATCH (DBI::dr=HASH(0x2428bdc) rc1/1 @1 g0
ima10004 pid#29840) during global destruction
! <> DESTROY(DBI::dr=HASH(0x2428bdc)) ignored for outer handle
(inner DBI::dr=HASH(0x245a424) has ref cnt 1)
! >> DESTROY DISPATCH (DBI::dr=HASH(0x245a424) rc1/1 @1 g0
ima10004 pid#29840) during global destruction
! -> DESTROY in DBD::_::common for DBD::mysql::dr
(DBI::dr=HASH(0x245a424)~INNER) thr#3424c
! <- DESTROY= undef during global destruction
DESTROY (dbih_clearcom) (drh 0x245a424, com 0x1836ffc, imp global
destruction):
FLAGS 0x100215: COMSET Active Warn PrintWarn AutoCommit
PARENT undef
KIDS 0 (0 Active)
dbih_clearcom 0x245a424 (com 0x1836ffc, type 1) done.

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
Elt "CntValues" HASH = 0x359bb702
SV = IV(0x230a7b0) at 0x230a7b4
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 0
Elt "MaxSubClassLen" HASH = 0xb3d551a2
SV = IV(0x230a860) at 0x230a864
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 0
Elt "FLAGS" HASH = 0x1773e623
SV = IV(0x230a9c0) at 0x230a9c4
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 136

Trace:
k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/
NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry:ESTROY, C:/
Perl/site/lib/Win32/TieRegistry.pm, Line: 1488
Carp::confess, C:/Perl/lib/Carp.pm, Line: 45

huh? at C:/Perl/site/lib/Win32/TieRegistry.pm line 1488
Win32::TieRegistry:ESTROY('Win32::TieRegistry=HASH(0x1c53074)')
called at k:/Projects/NewRiskModel/Simple.Risk.Model.pl line 0
eval {...} called at k:/Projects/NewRiskModel/Simple.Risk.Model.pl
line 0

Compilation finished at Wed May 19 20:59:57


Adding your four lines seems to have added the lines beginning with SV
= RV(0x22c15b0) at 0x22c15a4, but none of that info means anything to
me.

Any light that can be shed on this would be appreciated.

Thanks

Ted

 

[Steve M]

I have done all the usual things (as specified in the FAQ), and more,
but it isn't enough.

Here is how my script starts:

use strict;
use warnings;
use DBI;
use DateTime::Format::MySQL;
use Date::Manip;
use DateTime::Format:ateManip;

At no time have I made direct use of the file mentioned, so it must be
something one of the above packages has done.

Well. Maybe. At least indirectly. Win32::TieRegistry is being called by
something else, and I'm wondering.....

I've done a little digging, and one article I ran across said that DBI
worked fine with Sybase and an older Oracle, but a *newer* copy of
Oracle gave the error message you are getting.

Hmmm...... I definitely getting the impression it may be a driver issue
of some kind...

Probably wrong, but I'd certainly look into it. Maybe even try a clean
install of Strawberry Perl. (I recommend it because though I've used
Activestate for years it recently annoyed me for the last time.

Ah.. if you do install Strawberry, more than likely you'll want to check
your paths if 'things' don't work out of the box. On my 'Doze machine, I
had to fiddle the path to Perl.

hth,

\s

 

[Ted Byers]

Quoth Ted Byers <[email protected]>:








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:eek:ump line you
added before to

    Devel:eek:ump($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

 

[Ted Byers]

Quoth Ted Byers <[email protected]>:








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:eek:ump line you
added before to

    Devel:eek:ump($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

 

[Ted Byers]

Quoth Ted Byers <[email protected]>:








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:eek:ump line you
added before to

    Devel:eek:ump($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

 

[Ted Byers]

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.