| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
Subroutine cmd_l() no longer exists.
Now we should call cmd_l_main().
|
| | |
|
| |
|
|
|
| |
Since the '.' and '-' commands don't take any arguments and don't run if any are provided, don't treat commands starting with these characters as the single commands '.' and '-'. Restores behavior that existed prior to https://github.com/Perl/perl5/commit/7fdd4f080863703d44282c6988834455d129040 (v5.27) at least back to v5.8.8
https://github.com/Perl/perl5/commit/7fdd4f080863703d44282c6988834455d129040
|
| | |
|
| | |
|
| |
|
|
|
| |
As with `i $obj` the DB::Obj in the call stack prevented DB::eval
from compiling/executing in the context of the debugged code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the DB::eval function depends on the special behaviour of eval ""
within the DB package, which evaluates the string within the context
of the first non-DB sub or eval scope, working up the call stack.
The debugger refactor moved handling for the 'i' command from the
DB package to the DB::Obj package, so the eval in DB::eval was
working in the context of the DB::Obj::cmd_i function, not in the
calling scope.
Fixed by moving the handling for the i command back to DB.
Fixes #17661.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This requires a few small changes.
1. add a new option, which I stored in what looked like one of the
standard ways
2. only store the item in terminal history if >= this length
3. only add to @hist if >= this length
4. only display hist item if >= this length
I believe #4 is redundant and should be removed, but the code was
already effectively there.
|
| |
|
|
| |
as it's cleared right after it's been run.
|
| |
|
|
|
|
|
| |
When running with "c", there was no problem, but when running with "n"
or "s", once the action was executed, it kept executing on the
following lines, which wasn't expected. Clearing $action here prevents
this unwanted behaviour.
|
| |
|
|
|
| |
Mostly in comments and docs, but some in diagnostic messages and one
case of 'or die die'.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't know how this ever worked.
Previously, DB::sub() would hold a lock on $DB::DBGR for it's entire
body, including the call to the subroutine being called.
This could cause problems in two cases:
a) on creation of a new thread, CLONE() is called in the context of
the new interpreter before the new thread is created. So you'd have a
sequence like:
threads->new
DB::sub for threads::new (lock $DBGR)
call into threads::new which creates a new interpreter
Cwd::CLONE() (in the new interpreter)
DB::sub for Cwd::CLONE (in the new interpreter) (deadlock trying to lock $DBGR)
One workaround I tried for this was to prevent pp_entersub calling
DB::sub if we were cloning (by checking PL_ptr_table). This did
improve matters, but wasn't needed in the final patch.
Note that the recursive lock on $DBGR would have been fine if the new
code was executing in the same interpreter, since the locking code
simply bumps a reference count if the current interpreter already
holds the lock.
b) when the called subroutine blocks. For the test case this could
happen with the call to $thr->join. There would be a sequence like:
(parent) $thr->join
(parent) DB::sub for threads::join (lock $DBGR)
(parent) call threads::join and block
(child) try to call main::sub1
(child) DB::sub for main::sub1 (deadlock trying to lock $DBGR)
This isn't limited to threads::join obviously, one thread could be
waiting for input, sleeping, or performing a complex calculation.
The solution I chose here was the obvious one - don't hold the lock
for the actual call.
This required some rearrangement of the code and removed some
duplication too.
|
| |
|
|
|
|
|
|
| |
Committer: For porting tests: Update $VERSION in 4 files.
Run:
./perl -Ilib regen/mk_invlists.pl
./perl -Ilib regen/regcharclass.pl
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dump_trace() prints a stack backtrace - including caller args - by using
caller() and @DB::args.
However, if a sub is called using the '&foo;' argless mechanism, caller()
doesn't populate @DB::args, so it continues to hold whatever it was set
to previously. This might include SVs which have since been freed or
re-allocated.
So only display args for a particular caller depth if that sub was called
with args.
This was causing smoke failures in lib/perl5db.t when TERM was unset.
It only started failing recently, due I guess to subtle changes in what
SVs were left hanging about in @DB::args from a previous use of caller().
See http://nntp.perl.org/group/perl.perl5.porters/247032
Subject: Smoke FAIL's for lib/perl5db.t
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Make debugger commands like these work again, not requiring a space
between a single-letter command and a following argument which starts with
punctuation:
p$^V
x@ARGV
x\@ARGV
x\%INC
Regressions were in d478d7a0 and 8f144dfc.
|
| |
|
|
|
|
|
|
|
| |
If a Win32 system happens to have a \dev\tty file at the root of the current
drive, we were incorrectly treating that as an indicator that the system is
in fact Unix-like.
Fix this by looking at the filesystem for that file only after considering
all the OS platforms that we know aren't Unix-like in that way.
|
| |
|
|
|
|
|
|
|
|
| |
Switch from two-argument form. Filehandle cloning is still done with the two
argument form for backward compatibility.
Committer: Get all porting tests to pass. Increment some $VERSIONs.
Run: ./perl -Ilib regen/mk_invlists.pl; ./perl -Ilib regen/regcharclass.pl
For: RT #130122
|
| |
|
|
|
|
| |
Add a note about version numbering, since if we use X.XX_XX versions
in blead it's harder to find an unused version number if the module
is modified in maint.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Patch submitted by Shlomi Fish.
For: RT #126735
|
| |
|
|
|
| |
Credits to Heiko Eissfeldt for the reported bug, the test program and a
proposed fix.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cde405a6b9b86bd8110f63531b42d89590a4c56e removed the lock prototype
"because it's already a do-nothing weak keyword without threads".
However, that causes "perl -d threaded-script.pl" to complain
lock can only be used on shared values at /usr/share/perl/5.20/perl5db.pl line 4101.
BEGIN failed--compilation aborted at threaded-script.pl line 2.
lock can only be used on shared values at /usr/share/perl/5.20/perl5db.pl line 2514.
END failed--call queue aborted at threaded-script.pl line 2.
Unbalanced scopes: 3 more ENTERs than LEAVEs
because threaded-script.pl's importing of threads::shared enable's
lock()'s non-noop behavior. Restoring the lock() prototype fixes the
inconsistency between lock() and share() usage.
Signed-off-by: James McCoy <vega.james@gmail.com>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several /lib .pm's have the same code which is complicated enough to
warrant being placed in a shared function. This commit creates a .pm
to be used by these .pm's.
This implements the perhaps archaic 'Meta' notation wherein characters
above 0x7f are displayed as M- plus the ASCII-range character derived by
looking at only the lower 7 bits of the upper range one. There are
problems with this, in that a literal control character can be in the
string, whereas it is trying to get rid of control characters. But I
left it to work as-is, just centralizing the code.
On EBCDIC platforms this notation makes no sense because the bit
patterns are all mixed up about having the upper bit set. So this
commit fixes things on these platforms, so these are changed to
\x{...}. No literal control characters are emitted.
Another potential problem is that characters above 0xFF are passed
through, unchanged. But again, I let the existing behavior stand.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Perl debugger sometimes tries to call a non-existent subroutine
db_warn. It's real name is _db_warn, though.
How to replicate:
perl -d -e1
!/
Output:
/bin/bash: /: Is a directory
Undefined subroutine &DB::db_warn called at /usr/lib/perl5/5.18.1/perl5db.pl line 6740.
at /usr/lib/perl5/5.18.1/perl5db.pl line 6740.
DB::_db_system('/bin/bash', '-c', '/') called at /usr/lib/perl5/5.18.1/perl5db.pl line 3923
DB::Obj::_handle_sh_command('DB::Obj=HASH(0x105df48)') called at /usr/lib/perl5/5.18.1/perl5db.pl line 2992
DB::DB called at -e line 1
|
| |
|
|
|
|
| |
5c2b78e73d3 moved handling of the y command into its own function,
but did not adjust the provided scope level to account for the extra
scope.
|
| |
|
|
|
|
|
|
|
| |
See: https://rt.perl.org/Ticket/Display.html?id=121509
[perl #121509] perl debugger doesn't save starting dir to restart from
Thanks to Linda Walsh for reporting the problem and RJBS for commenting
for initial approval. Fix and a regression test by Shlomi Fish.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
[perl #121456]
|
| |
|
|
|
|
| |
Perhaps it also affects Term::ReadLine::Perl / Term::ReadLine::Perl5 .
I still need to test with PadWalker installed. No tests were added, but
it passes all existing tests.
|
| |
|
|
|
|
|
| |
A problem with the perl debugger of writing to an undef $LINEINFO.
Bump $VERSION to 1.42.
For: RT #41461
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ‘n’ debugger command, which is supposed to step over subs, was not
stepping over lvalue subs.
This is a regression from 5.8, but 5.8 was worse.
This bug did not occur in 5.8 because there was no mechanism back then
for handling lvalue subs specially (via DB::lsub), so assignment to an
lvalue sub was completely broken under the debugger.
Perl 5.10 introduced DB::lsub. The implementation in perl5db.pl
contains these lines at the end of the sub:
# Pop the single-step value back off the stack.
$single |= $stack[ $stack_depth-- ];
# call the original lvalue sub.
&$sub;
The regular DB::sub does this:
{
no strict 'refs';
@ret = &$sub;
}
# Pop the single-step value back off the stack.
$single |= $stack[ $stack_depth-- ];
Notice how $single (i.e., $DB::single) is modified before and after
the sub call, respectively. The order is different.
There are two types of lvalue list context for lvalue subs. (foo)=3
will allow sub foo:lvalue{@a} to return the array itself. \(foo) and
bar(foo) will flatten the array.
So there is no way in pure Perl to capture the return value and have
it returned to the caller unchanged. That is why DB::lsub has to call
the sub last of all (and have the context propagated).
The solution here is to use localisation to accomplish the assigment
to $single after the lvalue sub exits.
|
| |
|
|
| |
The regexp engine is now fully reëntrant.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
With a test.
See Father C.'s comment on RT #118169.
|
