Debugging question: tracing the origin of an error.
in [Perl]
|
From: RedGrittyBrick on 20 May 2010 12:51 On 20/05/2010 17:29, Ted Byers wrote: > > On a different note, any ideas why Google is sending my notes multiple > times to this forum? Not specifically. Maybe pressing the back button to view a prior page unaware that browsers resend form data when the previous page was the result of a form submission? Maybe just the general nastiness of Google Groups for anything other than searching archives? > This is actuall[y] the first time I have seen this nuisance arise. > If it matters, I am using Firefox to access usenet via google/groups. Firefox isn't the problem. > I have no other way to access this forum, or any other. If you have Firefox, you can probably have a NNTP news client like Thunderbird (or trn or Gravity or ...) Since you have internet access, an ISP is probably involved. Many ISPs provide news servers which their subscribers can access using an NNTP news reader. If not there are "free news servers" which you can find using Google or other search engines. ¤0.02 -- RGB
From: Ted Byers on 20 May 2010 14:37 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, <DATA> 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. I just made an observation that qualifies this. As I was watching the output from my script scroll by, I noticed that this confirmation applies only at the end of the program or when it is cleaning up when disconnecting from the DB ($dbh->disconnect();). This same code executes without error when cleaning up a statement handle ($sth->finish();). I see it every time I call $sth->finish() in preparation for preparing a new SQL statement: I reuse that statement handle variable at least half a dozen times. So this TieRegistry code works OK for $sth->finish but not $dbh->disconnect. Cheers Ted > > 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 withDBI, 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: Ben Morrow on 22 May 2010 09:43 Quoth Ted Byers <r.ted.byers(a)gmail.com>: > 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, <DATA> line 335 during global > > > > > destruction. > > > > > > 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 } <snip> > > > > 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. > > 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) OK, that's a perfectly ordinary non-existent hash element. I now have no idea at all what's going on. > What next? > > Would this be an issue with DBI, or the MySQL driver? It might. At this point the only possibility I can see is some sort of corruption of perl's stack, which could be caused by any XS module you are using. If you want to track this down further you will need to start producing a minimal failing example, which won't be easy if this is some sort of memory-corrupton bug since they tend to have unpredictable consequences. > 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. I seriously doubt it has anything to do with your registry. As for whether it's a problem or not, I really don't know without knowing the cause. If the program appears to do its job correctly you could decide to simply ignore it. Sorry I couldn't be more help. Ben
First
|
Prev
|
Pages: 1 2 3 4 5 6 Prev: FAQ 3.30 What's MakeMaker? Next: FAQ 8.41 How do I use an SQL database? |