From acahalan@gmail.com

I'm trying to debug pidl, the IDL compiler shipped with Samba and Ethereal.
Supposedly you can find it on CPAN.

Unlike gdb debugging C programs, the perl debugger is unable to place
breakpoints on things that don't yet exist. By this I mean functions
found in libraries that have yet to be loaded. It seems I have to somehow
find where the libraries get loaded, breakpoint that, single step, then
breakpoint what I want. This is awful, especially when dealing with
unfamiliar code. Here is the error message​:

  DB<9> b Parse​::Pidl​::Samba4​::EJS​::EjsPushArray
Subroutine Parse​::Pidl​::Samba4​::EJS​::EjsPushArray not found.

The below perlbug data is hacked a bit, since I shouldn't send bug
reports from work. FYI it's an AMD64 running Fedora Core 5.

Flags​:
  category=
  severity=

Site configuration information for perl​:

Summary of my perl5 configuration​:
  Platform​:
  osname=linux, osvers=2.6
  Compiler​:
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=1234

From @rgs

Albert Cahalan wrote​:

Unlike gdb debugging C programs, the perl debugger is unable to place
breakpoints on things that don't yet exist. By this I mean functions
found in libraries that have yet to be loaded. It seems I have to somehow
find where the libraries get loaded, breakpoint that, single step, then
breakpoint what I want. This is awful, especially when dealing with
unfamiliar code.

Doesn't the command "b postpone <subname>" work for you ? (See online
help by typing "h b" in the debugger)

The RT System itself - Status changed from 'new' to 'open'

From acahalan@gmail.com

On 4/25/06, Rafael Garcia-Suarez via RT <perlbug-followup@​perl.org> wrote​:

Albert Cahalan wrote​:

Unlike gdb debugging C programs, the perl debugger is unable to place
breakpoints on things that don't yet exist. By this I mean functions
found in libraries that have yet to be loaded. It seems I have to somehow
find where the libraries get loaded, breakpoint that, single step, then
breakpoint what I want. This is awful, especially when dealing with
unfamiliar code.

Doesn't the command "b postpone <subname>" work for you ? (See online
help by typing "h b" in the debugger)

Oh, OK. With gdb, the debugger just asks. That is nicer behavior.
So consider this bug report as an enhancement request for
gdb-like behavior. I'd rather let the debugger take care of tracking
whether or not "postpone " should be used.

The less the user needs to do, the less needs to be documented.

From @richardfoley

On Wednesday 26 April 2006 07​:38, Albert Cahalan wrote​:

On 4/25/06, Rafael Garcia-Suarez via RT <perlbug-followup@​perl.org> wrote​:

Albert Cahalan wrote​:

Unlike gdb debugging C programs, the perl debugger is unable to place
breakpoints on things that don't yet exist. By this I mean functions
found in libraries that have yet to be loaded. It seems I have to
somehow
find where the libraries get loaded, breakpoint that, single step, then
breakpoint what I want. This is awful, especially when dealing with
unfamiliar code.

Doesn't the command "b postpone <subname>" work for you ? (See online
help by typing "h b" in the debugger)

Oh, OK. With gdb, the debugger just asks. That is nicer behavior.
So consider this bug report as an enhancement request for
gdb-like behavior. I'd rather let the debugger take care of tracking
whether or not "postpone " should be used.

The less the user needs to do, the less needs to be documented.

You mean if you want to set a breakpoint on a subroutine, but you have spelt
it incorrectly, you want the debugger to read your mind, and to remain silent
on the basis that you _might_ have spelt it correctly, and you _might_ be
going to load it some time in the future. The debugger behaves correctly and
warns the unfortunate user of the failed breakpoint setting, while providing
for the case where they might actually know what they are doing with the
tools they are using.

On the other hand, if you really want your code to behave as if it knew what
you meant, at all times and without ever asking, I suggest you use the
Symbol​::Approx​::Sub module from Dave Cross - that will almost certainly do
what it _thinks_ you meant, every time you misspell something. It's
especially useful in production code...

  ;-)

--
Richard Foley
Ciao - shorter than aufwiedersehen

http​://www.oreilly.com/catalog/perldebugpr/index.html
http​://www.apress.com/book/bookDisplay.html?bID=399
http​://www.oreilly.com/catalog/rtessentials/index.html

From mcmahon@ibiblio.org

On Apr 26, 2006, at 9​:52 AM, Richard Foley wrote​:

On the other hand, if you really want your code to behave as if it
knew what
you meant, at all times and without ever asking, I suggest you use the
Symbol​::Approx​::Sub module from Dave Cross - that will almost
certainly do
what it _thinks_ you meant, every time you misspell something. It's
especially useful in production code...

And with Devel​::Command, you can rewire the debugger to your heart's
content by intercepting the 'b' command, using Symbol​::Approx​::Sub to
figure out the place you want to breakpoint, and then pass the
(amended) command on to the debugger, which will then Do What You Mean.

Now everybody's happy. :)

  --- Joe M.

From @jbenjore

On 4/26/06, Joe McMahon <mcmahon@​ibiblio.org> wrote​:

On Apr 26, 2006, at 9​:52 AM, Richard Foley wrote​:

On the other hand, if you really want your code to behave as if it
knew what
you meant, at all times and without ever asking, I suggest you use the
Symbol​::Approx​::Sub module from Dave Cross - that will almost
certainly do
what it _thinks_ you meant, every time you misspell something. It's
especially useful in production code...

SWI-Prolog has this really nice feature that echos just this idea​:

?- assert(foobar(1,2)).

Yes
?- foobaz(1,2).
Correct to​: foobar(1, 2)?
Please answer 'y' or 'n'?

The debugger could do something just like this​: make a guess and let
the user decide whether it's a good one or not.

Josh

From perl@nevcal.com

On approximately 4/26/2006 11​:18 AM, came the following characters from
the keyboard of Joshua ben Jore​:

On 4/26/06, Joe McMahon <mcmahon@​ibiblio.org> wrote​:

On Apr 26, 2006, at 9​:52 AM, Richard Foley wrote​:

On the other hand, if you really want your code to behave as if it
knew what
you meant, at all times and without ever asking, I suggest you use the
Symbol​::Approx​::Sub module from Dave Cross - that will almost
certainly do
what it _thinks_ you meant, every time you misspell something. It's
especially useful in production code...

SWI-Prolog has this really nice feature that echos just this idea​:

?- assert(foobar(1,2)).

Yes
?- foobaz(1,2).
Correct to​: foobar(1, 2)?
Please answer 'y' or 'n'?

The debugger could do something just like this​: make a guess and let
the user decide whether it's a good one or not.

For perl, with the postpone option, maybe the choices would better read​:

b foobaz
Choose to cancel 'c', postpone 'p' foobaz,
or fix 'f' to foobar​:

--
Glenn -- http​://nevcal.com/

A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking

From mcmahon@ibiblio.org

On Apr 26, 2006, at 9​:57 AM, Joe McMahon wrote​:

And with Devel​::Command, you can rewire the debugger to your
heart's content by intercepting the 'b' command, using
Symbol​::Approx​::Sub to figure out the place you want to breakpoint,
and then pass the (amended) command on to the debugger, which will
then Do What You Mean.

Right now Devel​::Command actually installs a hooked version of DB​::DB
when it's loaded (from .perldb). Obviously this means I have to keep
this up to date when we release new Perls; is it an idea to make the
debugger patch that enables the Devel​::Command hook an actual
official patch? It does nothing unless Devel​::Command is loaded. (No,
Devel​::Command should *not* be core. We should get a new debugger.)

  --- Joe M.

From acahalan@gmail.com

On 4/26/06, Richard Foley <Richard.Foley@​t-online.de> wrote​:

On Wednesday 26 April 2006 07​:38, Albert Cahalan wrote​:

On 4/25/06, Rafael Garcia-Suarez via RT <perlbug-followup@​perl.org> wrote​:

Albert Cahalan wrote​:

Unlike gdb debugging C programs, the perl debugger is unable to place
breakpoints on things that don't yet exist. By this I mean functions
found in libraries that have yet to be loaded. It seems I have to
somehow
find where the libraries get loaded, breakpoint that, single step, then
breakpoint what I want. This is awful, especially when dealing with
unfamiliar code.

Doesn't the command "b postpone <subname>" work for you ? (See online
help by typing "h b" in the debugger)

Oh, OK. With gdb, the debugger just asks. That is nicer behavior.
So consider this bug report as an enhancement request for
gdb-like behavior. I'd rather let the debugger take care of tracking
whether or not "postpone " should be used.

The less the user needs to do, the less needs to be documented.

You mean if you want to set a breakpoint on a subroutine, but you have spelt
it incorrectly, you want the debugger to read your mind, and to remain silent
on the basis that you _might_ have spelt it correctly, and you _might_ be
going to load it some time in the future. The debugger behaves correctly and
warns the unfortunate user of the failed breakpoint setting, while providing
for the case where they might actually know what they are doing with the
tools they are using.

That isn't how gdb works. Hopefully you have a recent copy of gdb handy.
Give it a try. My version 6.3 gdb does this​:

(gdb) break foo
Function "foo" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 2 (foo) pending.
(gdb)

From @kevindawson

when you use the debugger

try the command h h

and you will see

f filename Switch to viewing filename. File must be already loaded.
  filename may be either the full name of the file, or a regular
  expression matching the full file name​:
  f /home/me/foo.pl and f oo\. may access the same file.
  Evals (with saved bodies) are considered to be filenames​:
  f (eval 7) and f eval 7\b access the body of the 7th eval
  (in the order of execution).

source file Execute file containing debugger commands (may nest).

  DB<9> L
/usr/src/Padre/Padre-Plugin-Debug/scripts/ExSewi.pm​:
31​: my $fred = $_[0];
  break if (1)
sewi.pl​:
21​: say $fred;
  break if (1)

all you have to do is load the perl.pms and set b's

imho this should be closed

From [Unknown Contact. See original ticket]

when you use the debugger

try the command h h

and you will see

f filename Switch to viewing filename. File must be already loaded.
  filename may be either the full name of the file, or a regular
  expression matching the full file name​:
  f /home/me/foo.pl and f oo\. may access the same file.
  Evals (with saved bodies) are considered to be filenames​:
  f (eval 7) and f eval 7\b access the body of the 7th eval
  (in the order of execution).

source file Execute file containing debugger commands (may nest).

  DB<9> L
/usr/src/Padre/Padre-Plugin-Debug/scripts/ExSewi.pm​:
31​: my $fred = $_[0];
  break if (1)
sewi.pl​:
21​: say $fred;
  break if (1)

all you have to do is load the perl.pms and set b's

imho this should be closed