Prev: export symbols
Next: Checking Perl 5.8.0 programs.
From: Marc Girod on 23 Jun 2010 09:19 On Jun 23, 1:58 pm, Marc Girod <marc.gi...(a)gmail.com> wrote: > I failed to reproduce the problem in a narrow snippet: I narrowed one step more, calling the original DESTROY: use strict; use ClearCase::Argv; sub fun { my $thing = ClearCase::Argv->new; return qw(1 2 3); } print "Fun ", join(' ', fun), "\n"; exit 0 unless fun; print "End\n"; But, this doesn't make it fail. Now, what could I *add* to this if I wanted to reproduce the previous behaviour? Thanks, Marc
From: Marc Girod on 24 Jun 2010 07:49 I am sorry that my question didn't inspire anybody... I continue my debugging: DB<14> $mod = $sync->_lsco DB<15> p $mod DB<16> x $sync->_lsco 0 '/view/emagiro_t7/vobs/atcctest/foo/d' Er... funny, isn't it? I go to the return statement of the _lsco function, set 'trace' on, and do a 'r'. I get a transcript of running the DESTROY members for two objects (and I did fix something related since yesterday), and get now (end only): ClearCase::Argv::DESTROY(/home/emagiro/perl/lib/ClearCase/Argv.pm: 855): 855: $? |= $ret; list context return from ClearCase::SyncTree::_lsco: 0 '/view/emagiro_t7/vobs/atcctest/foo/d' ClearCase::SyncTree::checkin(/vobs/atcctest/ClearCase-SyncTree/blib/ lib/ClearCase/SyncTree.pm:1218): 1218: my %checkedout = map {$_ => 1} $self->_lsco; So, now the function would return something, but the address returned to is completely weird! That's not where I started from! As it seems, a different place in the code, where the same function is called!? I have corrupted my stack, as it seems... I'll run the same under an other perl... Marc
From: Marc Girod on 7 Jul 2010 13:22 I am back to my problem... On Jun 24, 12:49 pm, Marc Girod <marc.gi...(a)gmail.com> wrote: > I'll run the same under an other perl... I tried with perl 5.10.0 (until now, it was 5.8.8), and got a similar behaviour, albeit as it seems, with destructors called later (?!). In my case, this makes the trace simpler: ClearCase::SyncTree::_lsco(/vobs/atcctest/ClearCase-SyncTree/blib/lib/ ClearCase/SyncTree.pm:214): 214: return sort keys %co; DB<4> x %co 0 '/view/emagiro_86/vobs/atcctest/foo/d' 1 1 DB<5> t Trace = on DB<5> r scalar context return from ClearCase::SyncTree::_lsco: undef main::(blib/script/synctree:321): exit $rc unless $mod; DB<5> x $mod main::((eval 43)[/vobs/cello/cade_A_tools_perl/lib/5.10.0/perl5db.pl: 638]:2): 2: $mod; 0 undef This is the return from the _lsco member function, which gets assigned to $mod. I would expect a defined value of 1. Am I wrong? Marc
From: Marc Girod on 7 Jul 2010 13:57 On Jul 7, 6:22 pm, Marc Girod <marc.gi...(a)gmail.com> wrote: > Am I wrong? Yes, but why? I reproduced it: $ cat foo #!/usr/bin/perl -w sub foo { my %co = (a=>1, b=>2); return sort keys %co; } my $mod = foo || foo || foo || foo; print "$mod\n"; $ perl -d ./foo Loading DB routines from perl5db.pl version 1.3 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(./foo:8): my $mod = foo || foo || foo || foo; DB<1> c 5 main::foo(./foo:5): return sort keys %co; DB<2> r scalar context return from main::foo: undef main::foo(./foo:4): my %co = (a=>1, b=>2); DB<2> q $ This works without 'sort'... Marc
From: Marc Girod on 7 Jul 2010 14:11
On Jul 7, 6:57 pm, Marc Girod <marc.gi...(a)gmail.com> wrote: > This works without 'sort'... or like this: sub foo { my %co = (a=>1, b=>2); my @ret = sort keys %co; return @ret; } Marc |