lexical "my" variables not visible in debugger "x" command #6142
Comments
From [email protected]Created by [email protected]I can no longer use the "x" debugger command to dd:dcd$ perl -de '$aa=1;my $bb=2;print "$aa,$bb\n";' Loading DB routines from perl5db.pl version 1.19 Enter h or `h h' for help, or `man perldebug' for more help. main::(-e:1): $aa=1;my $bb=2;print "$aa,$bb\n"; Perl Info |
From @andk
> I can no longer use the "x" debugger command to > dd:dcd$ perl -de '$aa=1;my $bb=2;print "$aa,$bb\n";' > Loading DB routines from perl5db.pl version 1.19 > Enter h or `h h' for help, or `man perldebug' for more help. > main::(-e:1): $aa=1;my $bb=2;print "$aa,$bb\n"; Introduced by patch 18220. Change 18220 by hv@hv-crypt.org on 2002/12/02 00:58:54 Subject: [PATCH 2nd attempt] allow evals to see the full lexical scope It would be really cool if we had tests for the debugger. Does anybody -- |
From @mjdominusandreas.koenig@anima.de (Andreas J. Koenig):
The debugger should have a well-defined programmatic interface. The I said on Sunday: If [the debugger internals] were more rational and open, with Being able to test the debugger would be another benefit of having Fixing the debugger would not necessarily require a lot of study and |
From [email protected]On 10 Dec 2002 at 18:40 -0000, Andreas Koenig <perlbug-followup@perl.org>
I suspected that patch also (based on the subject). As for test cases, wasn't someone working on an API to |
From @iabynOn Tue, Dec 10, 2002 at 01:51:59PM -0500, Mark Jason Dominus wrote:
Isn't DB.pm and DB.t an attempt to provide such a programmatic interface? PS - I should have a fix for the bug in question in a few days - I just -- |
From @mjdominusDave Mitchell <davem@fdgroup.com>:
It looks like it is. But the debugger doesn't actually use DB.pm, so The next step would be to rewrite the debugger as a thin layer atop |
From @gsarOn Wed, 11 Dec 2002 08:32:20 EST, Mark Jason Dominus wrote:
Just for laughs, here's something that uses DB.pm (the Swat debugger Sarathy begin 644 Swat-1.33.tar.gz |
From @hvdsMark Jason Dominus <mjd@plover.com> wrote: I'm sure someone was proposing to clean up the debugger, possibly Hugo |
From @mjdominushv@crypt.org:
Joe McMahon gave a lightning talk about it. Perhaps that's what |
From @pjscottIn article <rt-19017-44686.8.44962310026816@bugs6.perl.org>,
FWIW, this bug was introduced since 18154, which was the last patchlevel I had. -- |
From @iabynOn Tue, Dec 10, 2002 at 05:05:26PM -0000, Peter Scott wrote:
Yes, it was intoduced by a patch of mine. I didn't realise that eval '' Dave. -- |
From @mjdominus
Oho! I've always wondered how that worked. Thanks! That's the only reason that the debugger can dump out the contents of |
From @iabynOn Wed, Dec 11, 2002 at 08:36:06PM +0000, Dave Mitchell wrote:
Okay, here's the patch. Note that it's behaviour is slighlty different In olden times, an eval appearing within package DB would see both its This new version doesn't see its own scope at all. This may regarded Dave. -- # This is a patch for 18272.pad3a to update it to 18272.pad4 #### Patch data follows #### Inline Patch--- ./embed.fnc Tue Dec 10 02:07:18 2002
+++ ./embed.fnc Thu Dec 12 23:07:45 2002
@@ -1353,7 +1353,7 @@ sd |void |cv_dump |CV *cv|char *title
# endif
s |CV* |cv_clone2 |CV *proto|CV *outside
#endif
-pd |CV* |find_runcv
+pd |CV* |find_runcv |U32 *db_seqp
diff -up '18272.pad3a/pod/perlfunc.pod' '18272.pad4/pod/perlfunc.pod'
Inline Patch--- ./pod/perlfunc.pod Tue Dec 10 01:45:09 2002
+++ ./pod/perlfunc.pod Fri Dec 13 00:27:00 2002
@@ -1449,6 +1449,11 @@ in case 6.
C<eval BLOCK> does I<not> count as a loop, so the loop control statements
C<next>, C<last>, or C<redo> cannot be used to leave or restart the block.
+Note that as a very special case, an C<eval ''> executed within the C<DB>
+package doesn't see the usual surrounding lexical scope, but rather the
+scope of the first non-DB piece of code that called it. You don't normally
+need to worry about this unless you are writing a Perl debugger.
+
=item exec LIST
=item exec PROGRAM LIST
diff -up '18272.pad3a/pp_ctl.c' '18272.pad4/pp_ctl.c'
Inline Patch--- ./pp_ctl.c Tue Dec 10 02:07:18 2002
+++ ./pp_ctl.c Thu Dec 12 23:11:53 2002
@@ -2615,7 +2615,7 @@ Perl_sv_compile_2op(pTHX_ SV *sv, OP** s
/* we get here either during compilation, or via pp_regcomp at runtime */
runtime = PL_op && (PL_op->op_type == OP_REGCOMP);
if (runtime)
- runcv = find_runcv();
+ runcv = find_runcv(NULL);
PL_op = &dummy;
PL_op->op_type = OP_ENTEREVAL;
@@ -2649,22 +2649,35 @@ Perl_sv_compile_2op(pTHX_ SV *sv, OP** s
=for apidoc find_runcv
Locate the CV corresponding to the currently executing sub or eval.
+If db_seqp is non_null, skip CVs that are in the DB package and populate
+*db_seqp with the cop sequence number at the point that the DB:: code was
+entered. (allows debuggers to eval in the scope of the breakpoint rather
+than in in the scope of the debuger itself).
=cut
*/
CV*
-Perl_find_runcv(pTHX)
+Perl_find_runcv(pTHX_ U32 *db_seqp)
{
I32 ix;
PERL_SI *si;
PERL_CONTEXT *cx;
+ if (db_seqp)
+ *db_seqp = PL_curcop->cop_seq;
for (si = PL_curstackinfo; si; si = si->si_prev) {
for (ix = si->si_cxix; ix >= 0; ix--) {
cx = &(si->si_cxstack[ix]);
- if (CxTYPE(cx) == CXt_SUB || CxTYPE(cx) == CXt_FORMAT)
- return cx->blk_sub.cv;
+ if (CxTYPE(cx) == CXt_SUB || CxTYPE(cx) == CXt_FORMAT) {
+ CV *cv = cx->blk_sub.cv;
+ /* skip DB:: code */
+ if (db_seqp && PL_debstash && CvSTASH(cv) == PL_debstash) {
+ *db_seqp = cx->blk_oldcop->cop_seq;
+ continue;
+ }
+ return cv;
+ }
else if (CxTYPE(cx) == CXt_EVAL && !CxTRYBLOCK(cx))
return PL_compcv;
}
@@ -3222,6 +3235,7 @@ PP(pp_entereval)
STRLEN len;
OP *ret;
CV* runcv;
+ U32 seq;
if (!SvPV(sv,len))
RETPUSHUNDEF;
@@ -3269,7 +3283,12 @@ PP(pp_entereval)
PL_compiling.cop_io = newSVsv(PL_curcop->cop_io);
SAVEFREESV(PL_compiling.cop_io);
}
- runcv = find_runcv();
+ /* special case: an eval '' executed within the DB package gets lexically
+ * placed in the first non-DB CV rather than the current CV - this
+ * allows the debugger to execute code, find lexicals etc, in the
+ * scope of the code being debugged. Passing &seq gets find_runcv
+ * to do the dirty work for us */
+ runcv = find_runcv(&seq);
push_return(PL_op->op_next);
PUSHBLOCK(cx, (CXt_EVAL|CXp_REAL), SP);
@@ -3280,7 +3299,7 @@ PP(pp_entereval)
if (PERLDB_LINE && PL_curstash != PL_debstash)
save_lines(CopFILEAV(&PL_compiling), PL_linestr);
PUTBACK;
- ret = doeval(gimme, NULL, runcv, PL_curcop->cop_seq);
+ ret = doeval(gimme, NULL, runcv, seq);
if (PERLDB_INTER && was != (I32)PL_sub_generation /* Some subs defined here. */
&& ret != PL_op->op_next) { /* Successive compilation. */
strcpy(safestr, "_<(eval )"); /* Anything fake and short. */
diff -up '18272.pad3a/t/op/eval.t' '18272.pad4/t/op/eval.t'
Inline Patch--- ./t/op/eval.t Tue Dec 10 01:45:09 2002
+++ ./t/op/eval.t Fri Dec 13 00:18:51 2002
@@ -1,6 +1,6 @@
#!./perl
-print "1..78\n";
+print "1..84\n";
eval 'print "ok 1\n";';
@@ -349,3 +349,28 @@ eval q{ my $yyy = 888; my $zzz = 999; fr
print "ok 78\n";
}
+# evals that appear in the DB package should see the lexical scope of the
+# thing outside DB that called them (usually the debugged code), rather
+# than the usual surrounding scope
+
+our $x = 1;
+{
+ my $x=2;
+ sub db1 { $x; eval '$x' }
+ sub DB::db2 { $x; eval '$x' }
+ package DB;
+ sub db3 { eval '$x' }
+ sub DB::db4 { eval '$x' }
+ sub db5 { my $x=4; eval '$x' }
+ package main;
+ sub db6 { my $x=4; eval '$x' }
+}
+{
+ my $x = 3;
+ print db1() == 2 ? 'ok' : 'not ok', " $test\n"; $test++;
+ print DB::db2() == 2 ? 'ok' : 'not ok', " $test\n"; $test++;
+ print DB::db3() == 3 ? 'ok' : 'not ok', " $test\n"; $test++;
+ print DB::db4() == 3 ? 'ok' : 'not ok', " $test\n"; $test++;
+ print DB::db5() == 3 ? 'ok' : 'not ok', " $test\n"; $test++;
+ print db6() == 4 ? 'ok' : 'not ok', " $test\n"; $test++;
+}
#### ApplyPatch data follows #### #### End of Patch kit [created: Fri Dec 13 00:27:27 2002] #### |
From @pjscott
Argh, too many twisty little help text strings, all alike. In my defense I cite # eeevil ornaments enabled. This is an insane mess. Patch for 18292: Inline Patch--- lib/perl5db.pl.orig Thu Dec 12 10:10:09 2002
+++ lib/perl5db.pl Thu Dec 12 10:16:00 2002
@@ -2738,6 +2738,7 @@
B<V> [I<pkg> [I<vars>]] List some (default all) variables in package (default current).
Use B<~>I<pattern> and B<!>I<pattern> for positive and negative regexps.
B<X> [I<vars>] Same as \"B<V> I<currentpackage> [I<vars>]\".
+B<y> [I<n> [I<Vars>]] List lexicals in higher scope <n>. Vars same as B<V>.
B<x> I<expr> Evals expression in list context, dumps the result.
B<m> I<expr> Evals expression in list context, prints methods callable
on the first element of the result.
-- Peter Scott |
From @iabynOn Thu, Dec 12, 2002 at 11:42:35PM +0000, Dave Mitchell wrote:
Whoops!. It needs the following fix on top, otherwise the test fails. Inline Patch--- t/op/eval.t.1 Sat Dec 14 20:20:01 2002
+++ t/op/eval.t Sat Dec 14 20:21:37 2002
@@ -353,6 +353,7 @@
# thing outside DB that called them (usually the debugged code), rather
# than the usual surrounding scope
+$test=79;
our $x = 1;
{
my $x=2; |
From @rgsDave Mitchell wrote:
Thanks, both patches applied as #18307. I personnally think that the new |
From @rgsPeter Scott wrote:
Thanks, applied as #18308. |
From [email protected]On Mon, 16 Dec 2002 at 23:12 -0000, Rafael Garcia-Suarez <perlbug-followup@...:
I applied the patches by hand, and then had to do a little hand #18307 seems to fix the problem for me, thanks to all... |
From @jhiSeems to have been resolved, marking the problem ticket as such. |
|
@jhi - Status changed from 'new' to 'resolved' |
Migrated from rt.perl.org#19017 (status was 'resolved')
Searchable as RT19017$
The text was updated successfully, but these errors were encountered: