perl.debugger http://www.nntp.perl.org/group/perl.debugger/ ... Copyright 1998-2014 perl.org Fri, 24 Oct 2014 10:24:24 +0000 ask@perl.org Re: Tmux helps to debug perl fork()s by Peter Vereshagin Hello.<br/><br/>2012/12/03 12:48:41 -0500 Rocky Bernstein &lt;rocky@cpan.org&gt; =&gt; To Peter Vereshagin :<br/>RB&gt; On Mon, Dec 3, 2012 at 9:06 AM, Peter Vereshagin &lt;peter@vereshagin.org&gt;wrote:<br/>RB&gt; <br/>RB&gt; &gt; Hello.<br/>RB&gt; &gt;<br/>RB&gt; &gt; 2012/12/03 08:51:28 -0500 Rocky Bernstein &lt;rocky@cpan.org&gt; =&gt; To Richard<br/>RB&gt; &gt; Foley :<br/>RB&gt; &gt; RB&gt; Something I think about when I read about things like this whether<br/>RB&gt; &gt; there<br/>RB&gt; &gt; RB&gt; some sort of unifying principle that could be used in other debuggers<br/>RB&gt; &gt; or<br/>RB&gt; &gt; RB&gt; for other similar sorts of programs. Is there some support that a<br/>RB&gt; &gt; debugger<br/>RB&gt; &gt; RB&gt; should be providing to make things like this easier?<br/>RB&gt; &gt;<br/>RB&gt; &gt; I think it&#39;s about a standard for the program interface that majority of<br/>RB&gt; &gt; debuggers should follow.<br/>RB&gt; &gt;<br/>RB&gt; <br/>RB&gt; I&#39;m not sure what you mean. Suggest something.<br/><br/>api reference as a kind of unified principle described.<br/><br/>RB&gt; &gt; Debug::Fork::Tmux can redefine some other function (and/or a global<br/>RB&gt; &gt; variable)<br/>RB&gt; &gt; from another debugger. In this case the feature to implement can be the<br/>RB&gt; &gt; &#39;let<br/>RB&gt; &gt; user to tweak a namespace other than DB to inject to&#39;. Very obvious.<br/>RB&gt; &gt;<br/>RB&gt; <br/>RB&gt; Devel::Trepan has lots of non-DB spaces one can tweak to. But again, I am<br/>RB&gt; not exactly sure what you mean so it would help if you could be very<br/>RB&gt; specific.<br/><br/>For Debug::Fork::Tmux there&#39;s a DB::get_fork_TTY() to define and $DB::fork_TTY<br/>to assign to. (a tty name for the next debugger&#39;s process).<br/><br/>I have no idea if any other debugger use this in the same way.<br/><br/>RB&gt; &gt; RB&gt; Too often, especially with the venerable Perl debugger, you read about<br/>RB&gt; &gt; RB&gt; patch someone has that made that does some interesting thing. Or s a<br/>RB&gt; &gt; trick<br/>RB&gt; &gt; RB&gt; you can do in order to get something done that is commonly needed. It<br/>RB&gt; &gt; feels<br/>RB&gt; &gt; RB&gt; less like the &quot;art&quot; but rather knowing about a number of isolated<br/>RB&gt; &gt; tricks,<br/>RB&gt; &gt; RB&gt; or worse, workarounds that is relevant for one debugger on one<br/>RB&gt; &gt; programming<br/>RB&gt; &gt; RB&gt; language.<br/>RB&gt; &gt;<br/>RB&gt; &gt; I don&#39;t patch the debugger, sorry.<br/>RB&gt; &gt;<br/>RB&gt; &gt; When needed, the critical mass of &#39;isolated tricks and workarounds&#39; can be<br/>RB&gt; &gt; collected into one distribution, and documented in details in one place,<br/>RB&gt; &gt; can&#39;t<br/>RB&gt; &gt; them?<br/>RB&gt; &gt;<br/>RB&gt; &gt; RB&gt; That said, of course, all of this is cool.<br/>RB&gt; &gt;<br/>RB&gt; &gt; Great.<br/>RB&gt; &gt;<br/>RB&gt; &gt; My main target with Debug::Fork::Tmux was to make a convinient build<br/>RB&gt; &gt; environment, including docs, for better and faster releasing.<br/>RB&gt; &gt;<br/>RB&gt; &gt; Otherwise the one can use a couple of lines to use Tmux for that same<br/>RB&gt; &gt; purpose.<br/>RB&gt; &gt;<br/>RB&gt; &gt; RB&gt; &gt; Here is an interesting module from Peter Vereshagin which might help<br/>RB&gt; &gt; with<br/>RB&gt; &gt; RB&gt; &gt; debugging forks under the perl debugger, if you use tmux version 1.6+<br/>RB&gt; &gt; RB&gt; &gt;<br/>RB&gt; &gt; RB&gt; &gt; http://search.cpan.org/dist/Debug-Fork-Tmux<br/><br/>--<br/>Peter Vereshagin &lt;peter@vereshagin.org&gt; (http://vereshagin.org) pgp: A0E26627 <br/> http://www.nntp.perl.org/group/perl.debugger/2012/12/msg163.html Tue, 04 Dec 2012 21:35:00 +0000 Re: Tmux helps to debug perl fork()s by Peter Vereshagin Hello.<br/><br/>2012/12/03 10:34:27 +0100 Richard Foley &lt;richard.foley@rfi.net&gt; =&gt; To debugger@perl.org :<br/>RF&gt; Here is an interesting module from Peter Vereshagin which might help with<br/>RF&gt; debugging forks under the perl debugger, if you use tmux version 1.6+<br/>RF&gt; <br/>RF&gt; http://search.cpan.org/dist/Debug-Fork-Tmux<br/><br/>Thank you very much Richard for your announce!<br/><br/>The latest development (v1.000010 currently) is at:<br/><br/> http://gitweb.vereshagin.org/Debug-Fork-Tmux/README.html<br/><br/>The latest Changes are:<br/><br/> Searching for tmux binary (in PATH) and perl-5.8.9 minimum (in POD)<br/><br/>Keeping at sight the things to improve (have them recorded).<br/><br/>There is a GitHub page, too:<br/><br/> https://github.com/petr999/Debug-Fork-Tmux<br/><br/>v1.000010 isn&#39;t yet on CPAN cause I always think twice before. This was just<br/>the case and I&#39;d like to redo the feature a bit.<br/><br/>If anyone is about to v1.00010 or any other version from Git then I should let<br/>know here that still on the list &#39;the missing test files from MANIFEST&#39; bug:<br/>find them all in CPAN archive as they are all the same each time.<br/><br/>RF&gt; http://www.rfi.net/books.html<br/><br/>--<br/>Peter Vereshagin &lt;peter@vereshagin.org&gt; (http://vereshagin.org) pgp: A0E26627 <br/> http://www.nntp.perl.org/group/perl.debugger/2012/12/msg162.html Tue, 04 Dec 2012 21:30:57 +0000 Re: Tmux helps to debug perl fork()s by Peter Vereshagin Hello.<br/><br/>2012/12/03 08:51:28 -0500 Rocky Bernstein &lt;rocky@cpan.org&gt; =&gt; To Richard Foley :<br/>RB&gt; Something I think about when I read about things like this whether there<br/>RB&gt; some sort of unifying principle that could be used in other debuggers or<br/>RB&gt; for other similar sorts of programs. Is there some support that a debugger<br/>RB&gt; should be providing to make things like this easier?<br/><br/>I think it&#39;s about a standard for the program interface that majority of<br/>debuggers should follow.<br/><br/>Debug::Fork::Tmux can redefine some other function (and/or a global variable)<br/>from another debugger. In this case the feature to implement can be the &#39;let<br/>user to tweak a namespace other than DB to inject to&#39;. Very obvious.<br/><br/>RB&gt; Too often, especially with the venerable Perl debugger, you read about<br/>RB&gt; patch someone has that made that does some interesting thing. Or s a trick<br/>RB&gt; you can do in order to get something done that is commonly needed. It feels<br/>RB&gt; less like the &quot;art&quot; but rather knowing about a number of isolated tricks,<br/>RB&gt; or worse, workarounds that is relevant for one debugger on one programming<br/>RB&gt; language.<br/><br/>I don&#39;t patch the debugger, sorry.<br/><br/>When needed, the critical mass of &#39;isolated tricks and workarounds&#39; can be<br/>collected into one distribution, and documented in details in one place, can&#39;t<br/>them?<br/><br/>RB&gt; That said, of course, all of this is cool.<br/><br/>Great.<br/><br/>My main target with Debug::Fork::Tmux was to make a convinient build<br/>environment, including docs, for better and faster releasing.<br/><br/>Otherwise the one can use a couple of lines to use Tmux for that same purpose.<br/><br/>RB&gt; &gt; Here is an interesting module from Peter Vereshagin which might help with<br/>RB&gt; &gt; debugging forks under the perl debugger, if you use tmux version 1.6+<br/>RB&gt; &gt;<br/>RB&gt; &gt; http://search.cpan.org/dist/Debug-Fork-Tmux<br/><br/>--<br/>Peter Vereshagin &lt;peter@vereshagin.org&gt; (http://vereshagin.org) pgp: A0E26627 <br/> http://www.nntp.perl.org/group/perl.debugger/2012/12/msg161.html Tue, 04 Dec 2012 21:30:52 +0000 Re: Tmux helps to debug perl fork()s by Richard Foley You&#39;re welcome, Peter, it&#39;s a quiet list, but there are some debugger relevant<br/>people on it ;-)<br/><br/>-- <br/>Ciao<br/><br/>Richard Foley<br/><br/>http://www.rfi.net/books.html<br/><br/>On Mon, Dec 03, 2012 at 03:11:34PM +0400, Peter Vereshagin wrote:<br/>&gt; Hello.<br/>&gt; <br/>&gt; 2012/12/03 10:34:27 +0100 Richard Foley &lt;richard.foley@rfi.net&gt; =&gt; To debugger@perl.org :<br/>&gt; RF&gt; Here is an interesting module from Peter Vereshagin which might help with<br/>&gt; RF&gt; debugging forks under the perl debugger, if you use tmux version 1.6+<br/>&gt; RF&gt; <br/>&gt; RF&gt; http://search.cpan.org/dist/Debug-Fork-Tmux<br/>&gt; <br/>&gt; Thank you very much Richard for your announce!<br/>&gt; <br/>&gt; The latest development (v1.000010 currently) is at:<br/>&gt; <br/>&gt; http://gitweb.vereshagin.org/Debug-Fork-Tmux/README.html<br/>&gt; <br/>&gt; The latest Changes are:<br/>&gt; <br/>&gt; Searching for tmux binary (in PATH) and perl-5.8.9 minimum (in POD)<br/>&gt; <br/>&gt; Keeping at sight the things to improve (have them recorded).<br/>&gt; <br/>&gt; There is a GitHub page, too:<br/>&gt; <br/>&gt; https://github.com/petr999/Debug-Fork-Tmux<br/>&gt; <br/>&gt; v1.000010 isn&#39;t yet on CPAN cause I always think twice before. This was just<br/>&gt; the case and I&#39;d like to redo the feature a bit.<br/>&gt; <br/>&gt; If anyone is about to v1.00010 or any other version from Git then I should let<br/>&gt; know here that still on the list &#39;the missing test files from MANIFEST&#39; bug:<br/>&gt; find them all in CPAN archive as they are all the same each time.<br/>&gt; <br/>&gt; RF&gt; http://www.rfi.net/books.html<br/>&gt; <br/>&gt; --<br/>&gt; Peter Vereshagin &lt;peter@vereshagin.org&gt; (http://vereshagin.org) pgp: A0E26627 <br/> http://www.nntp.perl.org/group/perl.debugger/2012/12/msg160.html Tue, 04 Dec 2012 10:10:40 +0000 Re: Tmux helps to debug perl fork()s by Rocky Bernstein On Mon, Dec 3, 2012 at 9:06 AM, Peter Vereshagin &lt;peter@vereshagin.org&gt;wrote:<br/><br/>&gt; Hello.<br/>&gt;<br/>&gt; 2012/12/03 08:51:28 -0500 Rocky Bernstein &lt;rocky@cpan.org&gt; =&gt; To Richard<br/>&gt; Foley :<br/>&gt; RB&gt; Something I think about when I read about things like this whether<br/>&gt; there<br/>&gt; RB&gt; some sort of unifying principle that could be used in other debuggers<br/>&gt; or<br/>&gt; RB&gt; for other similar sorts of programs. Is there some support that a<br/>&gt; debugger<br/>&gt; RB&gt; should be providing to make things like this easier?<br/>&gt;<br/>&gt; I think it&#39;s about a standard for the program interface that majority of<br/>&gt; debuggers should follow.<br/>&gt;<br/><br/>I&#39;m not sure what you mean. Suggest something.<br/><br/>&gt;<br/>&gt; Debug::Fork::Tmux can redefine some other function (and/or a global<br/>&gt; variable)<br/>&gt; from another debugger. In this case the feature to implement can be the<br/>&gt; &#39;let<br/>&gt; user to tweak a namespace other than DB to inject to&#39;. Very obvious.<br/>&gt;<br/><br/>Devel::Trepan has lots of non-DB spaces one can tweak to. But again, I am<br/>not exactly sure what you mean so it would help if you could be very<br/>specific.<br/><br/><br/><br/>&gt;<br/>&gt; RB&gt; Too often, especially with the venerable Perl debugger, you read about<br/>&gt; RB&gt; patch someone has that made that does some interesting thing. Or s a<br/>&gt; trick<br/>&gt; RB&gt; you can do in order to get something done that is commonly needed. It<br/>&gt; feels<br/>&gt; RB&gt; less like the &quot;art&quot; but rather knowing about a number of isolated<br/>&gt; tricks,<br/>&gt; RB&gt; or worse, workarounds that is relevant for one debugger on one<br/>&gt; programming<br/>&gt; RB&gt; language.<br/>&gt;<br/>&gt; I don&#39;t patch the debugger, sorry.<br/>&gt;<br/>&gt; When needed, the critical mass of &#39;isolated tricks and workarounds&#39; can be<br/>&gt; collected into one distribution, and documented in details in one place,<br/>&gt; can&#39;t<br/>&gt; them?<br/>&gt;<br/>&gt; RB&gt; That said, of course, all of this is cool.<br/>&gt;<br/>&gt; Great.<br/>&gt;<br/>&gt; My main target with Debug::Fork::Tmux was to make a convinient build<br/>&gt; environment, including docs, for better and faster releasing.<br/>&gt;<br/>&gt; Otherwise the one can use a couple of lines to use Tmux for that same<br/>&gt; purpose.<br/>&gt;<br/>&gt; RB&gt; &gt; Here is an interesting module from Peter Vereshagin which might help<br/>&gt; with<br/>&gt; RB&gt; &gt; debugging forks under the perl debugger, if you use tmux version 1.6+<br/>&gt; RB&gt; &gt;<br/>&gt; RB&gt; &gt; http://search.cpan.org/dist/Debug-Fork-Tmux<br/>&gt;<br/>&gt; --<br/>&gt; Peter Vereshagin &lt;peter@vereshagin.org&gt; (http://vereshagin.org) pgp:<br/>&gt; A0E26627<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2012/12/msg159.html Mon, 03 Dec 2012 17:48:49 +0000 Re: Tmux helps to debug perl fork()s by Rocky Bernstein Something I think about when I read about things like this whether there<br/>some sort of unifying principle that could be used in other debuggers or<br/>for other similar sorts of programs. Is there some support that a debugger<br/>should be providing to make things like this easier?<br/><br/>Too often, especially with the venerable Perl debugger, you read about<br/>patch someone has that made that does some interesting thing. Or s a trick<br/>you can do in order to get something done that is commonly needed. It feels<br/>less like the &quot;art&quot; but rather knowing about a number of isolated tricks,<br/>or worse, workarounds that is relevant for one debugger on one programming<br/>language.<br/><br/>That said, of course, all of this is cool.<br/><br/>On Mon, Dec 3, 2012 at 4:34 AM, Richard Foley &lt;richard.foley@rfi.net&gt; wrote:<br/><br/>&gt; Here is an interesting module from Peter Vereshagin which might help with<br/>&gt; debugging forks under the perl debugger, if you use tmux version 1.6+<br/>&gt;<br/>&gt; http://search.cpan.org/dist/Debug-Fork-Tmux<br/>&gt;<br/>&gt; --<br/>&gt; Ciao<br/>&gt;<br/>&gt; Richard Foley<br/>&gt;<br/>&gt; http://www.rfi.net/books.html<br/>&gt;<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2012/12/msg158.html Mon, 03 Dec 2012 13:51:37 +0000 Tmux helps to debug perl fork()s by Richard Foley Here is an interesting module from Peter Vereshagin which might help with<br/>debugging forks under the perl debugger, if you use tmux version 1.6+<br/><br/> http://search.cpan.org/dist/Debug-Fork-Tmux<br/><br/>-- <br/>Ciao<br/><br/>Richard Foley<br/><br/>http://www.rfi.net/books.html<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2012/12/msg157.html Mon, 03 Dec 2012 09:34:38 +0000 Re: What is the history behind the DB module? by Rocky Bernstein On Fri, Sep 14, 2012 at 3:47 AM, Shlomi Fish &lt;shlomif@shlomifish.org&gt; wrote:<br/><br/>&gt; Hi Rocky,<br/>&gt;<br/>&gt; On Thu, 13 Sep 2012 19:40:53 -0400<br/>&gt; Rocky Bernstein &lt;rocky.bernstein@gmail.com&gt; wrote:<br/>&gt;<br/>&gt; &gt; http://perldoc.perl.org/DB.html mentions a &quot;programmatic interface to<br/>&gt; &gt; the Perl debugging API&quot;.<br/>&gt; &gt;<br/>&gt; &gt; As far as I can tell it hasn&#39;t really changed at all since Perl 5.8<br/>&gt; &gt; and not much between that and 5.6 except bug fixes. Why was this not<br/>&gt; &gt; more widely adopted?<br/>&gt;<br/>&gt; I guess not too many people need to write custom debuggers.<br/><br/><br/>I am weary of arguments of the form because if X isn&#39;t used much something<br/>that X attempts to address is not needed by too many people.<br/><br/>First, from what I&#39;ve seen there have been a number of &quot;custom debuggers&quot;<br/>including a large number of customization of perl5db: for remote execution<br/>or handling syntax highlighting. I just became aware of a recent YAPC paper<br/>on trying to automatically figure out when an input line in perl5db is not<br/>finished so as to offer another read rather than eval the line.<br/><br/>And consider dtrace which is popular. From what I understand, that is used<br/>for custom tracing which to me amounts to the same thing as debugging.<br/>dtrace doesn&#39;t sport a REPL although one could probably add that into the<br/>callback.<br/><br/>Now back to the DB module. Although it may appear to advertise itself as<br/>for writing REPL debuggers, it doesn&#39;t have to be used that way. So perhaps<br/>the DB API module was not advertising itself in not the most encompassing<br/>way.<br/><br/>One of the ideas that I think is right about the DB module is the fact that<br/>programs can register for a callback. Supposedly DB handles all of the<br/>lower-level boilerplate DB module stuff.<br/><br/>One might imagine registering a callback when various events occur to be<br/>something that should be put in the Perl core, but since all of this code<br/>can be written in Perl (as evidence by the DB module), why then put it in<br/>the Perl core?<br/><br/>And finally coming back to the original question, I was hoping that someone<br/>who was working on perl5db at the time could elaborate on what specifically<br/>happened here, rather than speculatively what might have happened.<br/><br/><br/><br/>&gt; Furthermore, it<br/>&gt; seems that many Perl developers avoid using the debugger in favour of print<br/>&gt; statements and other stuff like that.<br/>&gt;<br/>&gt; Regards,<br/>&gt;<br/>&gt; Shlomi Fish<br/>&gt;<br/>&gt; --<br/>&gt; -----------------------------------------------------------------<br/>&gt; Shlomi Fish http://www.shlomifish.org/<br/>&gt; What Makes Software Apps High Quality - http://shlom.in/sw-quality<br/>&gt;<br/>&gt; Quark: &ldquo;Too much of a good thing is a bad thing. But only for your<br/>&gt; customers&rdquo;.<br/>&gt; Rule of acquisition No. 172.<br/>&gt; &mdash; Star Trek, &ldquo;We, the Living Dead&rdquo; by Shlomi Fish<br/>&gt;<br/>&gt; Please reply to list if it&#39;s a mailing list post - http://shlom.in/reply .<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2012/09/msg156.html Fri, 14 Sep 2012 08:00:47 +0000 Re: What is the history behind the DB module? by Richard Foley Indeed.<br/><br/>You have to remember that just because some of us *like* using the debugger,<br/>many people do not. And there is a special kind of snobbery involved, something<br/>along the lines of:<br/><br/> &quot;Oh, so you NEED to use the debugger, do you....?&quot;<br/><br/>Should be read aloud with raised eyebrows ;-)<br/><br/>-- <br/>Ciao<br/><br/>Richard Foley<br/><br/>http://www.rfi.net/books.html<br/><br/>On Fri, Sep 14, 2012 at 10:47:16AM +0300, Shlomi Fish wrote:<br/>&gt; Hi Rocky,<br/>&gt; <br/>&gt; On Thu, 13 Sep 2012 19:40:53 -0400<br/>&gt; Rocky Bernstein &lt;rocky.bernstein@gmail.com&gt; wrote:<br/>&gt; <br/>&gt; &gt; http://perldoc.perl.org/DB.html mentions a &quot;programmatic interface to<br/>&gt; &gt; the Perl debugging API&quot;.<br/>&gt; &gt; <br/>&gt; &gt; As far as I can tell it hasn&#39;t really changed at all since Perl 5.8<br/>&gt; &gt; and not much between that and 5.6 except bug fixes. Why was this not<br/>&gt; &gt; more widely adopted?<br/>&gt; <br/>&gt; I guess not too many people need to write custom debuggers. Furthermore, it<br/>&gt; seems that many Perl developers avoid using the debugger in favour of print<br/>&gt; statements and other stuff like that.<br/>&gt; <br/>&gt; Regards,<br/>&gt; <br/>&gt; Shlomi Fish<br/>&gt; <br/>&gt; -- <br/>&gt; -----------------------------------------------------------------<br/>&gt; Shlomi Fish http://www.shlomifish.org/<br/>&gt; What Makes Software Apps High Quality - http://shlom.in/sw-quality<br/>&gt; <br/>&gt; Quark: &ldquo;Too much of a good thing is a bad thing. But only for your customers&rdquo;.<br/>&gt; Rule of acquisition No. 172.<br/>&gt; &mdash; Star Trek, &ldquo;We, the Living Dead&rdquo; by Shlomi Fish<br/>&gt; <br/>&gt; Please reply to list if it&#39;s a mailing list post - http://shlom.in/reply .<br/> http://www.nntp.perl.org/group/perl.debugger/2012/09/msg155.html Fri, 14 Sep 2012 01:48:40 +0000 Re: What is the history behind the DB module? by Shlomi Fish Hi Rocky,<br/><br/>On Thu, 13 Sep 2012 19:40:53 -0400<br/>Rocky Bernstein &lt;rocky.bernstein@gmail.com&gt; wrote:<br/><br/>&gt; http://perldoc.perl.org/DB.html mentions a &quot;programmatic interface to<br/>&gt; the Perl debugging API&quot;.<br/>&gt; <br/>&gt; As far as I can tell it hasn&#39;t really changed at all since Perl 5.8<br/>&gt; and not much between that and 5.6 except bug fixes. Why was this not<br/>&gt; more widely adopted?<br/><br/>I guess not too many people need to write custom debuggers. Furthermore, it<br/>seems that many Perl developers avoid using the debugger in favour of print<br/>statements and other stuff like that.<br/><br/>Regards,<br/><br/> Shlomi Fish<br/><br/>-- <br/>-----------------------------------------------------------------<br/>Shlomi Fish http://www.shlomifish.org/<br/>What Makes Software Apps High Quality - http://shlom.in/sw-quality<br/><br/>Quark: &ldquo;Too much of a good thing is a bad thing. But only for your customers&rdquo;.<br/>Rule of acquisition No. 172.<br/> &mdash; Star Trek, &ldquo;We, the Living Dead&rdquo; by Shlomi Fish<br/><br/>Please reply to list if it&#39;s a mailing list post - http://shlom.in/reply .<br/> http://www.nntp.perl.org/group/perl.debugger/2012/09/msg154.html Fri, 14 Sep 2012 00:47:26 +0000 Re: Call perl5db or trepan.pl from re.pl by Rocky Bernstein On Sat, Jan 7, 2012 at 11:42 PM (a long while ago), Rocky Bernstein<br/><br/>&gt; - - -<br/>&gt;<br/>&gt; I was looking at perl5db code and noticed that numeric value of @dbline is<br/>&gt; its COP reference. (In trepan.pl &quot;info program&quot; now shows this when it is<br/>&gt; available). I thought this would be a win for being able to more precisely<br/>&gt; indicate where you are and to set breakpoints within lines which have<br/>&gt; multiple statements on them.<br/>&gt;<br/>&gt; Such an example line might be:<br/>&gt;<br/>&gt; if ($x) { $y--; if ($y) { $z += 1 } else { $z -= 1 }; } else { $z = 10 };<br/>&gt;<br/>&gt; If you disassemble via B::Concise, you&#39;ll see several COPs for this line.<br/>&gt; However the @dbline entry for that line always seems to be the first COP<br/>&gt; rather than the one that called DB::DB.<br/>&gt;<br/><br/>What I&#39;ve been looking for is Devel::Callsite<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2012/09/msg153.html Thu, 13 Sep 2012 16:44:10 +0000 What is the history behind the DB module? by Rocky Bernstein http://perldoc.perl.org/DB.html mentions a &quot;programmatic interface to the<br/>Perl debugging API&quot;.<br/><br/>As far as I can tell it hasn&#39;t really changed at all since Perl 5.8 and not<br/>much between that and 5.6 except bug fixes. Why was this not more widely<br/>adopted?<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2012/09/msg152.html Thu, 13 Sep 2012 16:41:01 +0000 Call perl5db or trepan.pl from re.pl by Rocky Bernstein I recently I&#39;ve written Devel::REPL plugins to call a trepan or perl5db<br/>debugger from re.pl via Enbugger.<br/>If there are other plugins for this, I&#39;d be interested to compare.<br/><br/>https://github.com/rocky/Perl-Devel-Trepan-Shell has the code.<br/><br/>In my repl.rc load the plugins:<br/><br/> $_REPL-&gt;load_plugin(&#39;Trepan&#39;);<br/> $_REPL-&gt;load_plugin(&#39;Perl5db&#39;);<br/><br/>Then to get into the debugger<br/> %trepan your-code-here<br/><br/>or<br/> %perl5db some-other-code-here<br/><br/>More could be done to better show return values, and there are some<br/>weirdnesses in the trepan plugin when re.pl<br/>is exited, but overall it works.<br/><br/>- - -<br/><br/>I was looking at perl5db code and noticed that numeric value of @dbline is<br/>its COP reference. (In trepan.pl &quot;info program&quot; now shows this when it is<br/>available). I thought this would be a win for being able to more precisely<br/>indicate where you are and to set breakpoints within lines which have<br/>multiple statements on them.<br/><br/>Such an example line might be:<br/><br/>if ($x) { $y--; if ($y) { $z += 1 } else { $z -= 1 }; } else { $z = 10 };<br/><br/>If you disassemble via B::Concise, you&#39;ll see several COPs for this line.<br/>However the @dbline entry for that line always seems to be the first COP<br/>rather than the one that called DB::DB.<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2012/01/msg151.html Sat, 07 Jan 2012 20:42:50 +0000 Re: RFC Devel::Trepan by Rocky Bernstein On Sun, Dec 18, 2011 at 11:42 AM, Rocky Bernstein &lt;rocky@gnu.org&gt; wrote:<br/><br/>&gt; With the recent release of Devel::Trepan (0.1.4), I am at a juncture of<br/>&gt; next steps. So I thought I would solicit feedback. ...<br/><br/><br/>&gt; Other miscellaneous items:<br/>&gt;<br/>&gt; - adding history save/restore. Term::ReadLine::Perl doesn&#39;t have<br/>&gt; StifleHistory and ReadHistory. Perhaps the way to go would be to<br/>&gt; add those to Term::ReadLine::Perl<br/>&gt;<br/>&gt; - Add gdb-like signal handling routines &quot;handle&quot;.<br/>&gt;<br/><br/>Recent releases now have this. Some more shake-down is needed. But in<br/>doing this, the lack of evaluating frames other than the top became more<br/>apparent. When we enter the debugger&#39;s signal handler, the top-most frames<br/>are the debugger boilerplate subroutine; those subroutine(s) should be<br/>hidden and ignored.<br/><br/>Therefore, in preparation of improving evaluation in the signal handler, I<br/>added code to do evaluation via PadWalker and Eval::WithLexicals. It&#39;s<br/>better than nothing, but it is unreliable. So right now I give a warning<br/>when this code is used.<br/><br/>Given this unreliability and code complication, in my view changes to the<br/>Perl Runtime to add eval_n() is the most important thing that will help<br/>debugging.<br/><br/>Since Devel::Trepan debugger now supports Perl 5.8.8 and greater, I will<br/>have to keep the existing ugly mess of code around. But I will also need<br/>an alternative (simpler) version using eval_n(). I believe I can isolate<br/>existing evaluation code to a single file containing the two namespaces it<br/>needs: DB and Devel::Trepan::CmdProcessor. And I will also need some way to<br/>select between the two files at install time or run time.<br/><br/><br/><br/>&gt; - Making restart better by saving and restoring debugger state.<br/>&gt;<br/>&gt; - More remote debugging features.<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2012/01/msg150.html Mon, 02 Jan 2012 16:53:05 +0000 Re: breakpoint bug in the debugger by Rocky Bernstein At the risk of beating an already dead horse, since setting a breakpoint on<br/>a &quot;use&quot; statement is likely to continue to cause confusions like this, I&#39;ve<br/>added a hack in Devel::Trepan to see if the line that a breakpoint has been<br/>set at starts with the regexp /^\s*use\s+/. If so, a warning is issued<br/>given.<br/><br/>The breakpoint is still set - it is just a warning. There are many ways<br/>that this heuristic can fail. For example setting a breakpoint on a line<br/>with:<br/><br/>use English; $x = 3;<br/><br/>may &quot;skip&quot; the &quot;use&quot; and still stop on the assignment statement.<br/><br/>On Mon, Dec 19, 2011 at 12:20 AM, Rocky Bernstein &lt;rocky@cpan.org&gt; wrote:<br/><br/>&gt; A while back on Tue, 31 May 2011 18:20:51 -0700 Conor wrote:<br/>&gt;<br/>&gt; Not exactly a high priority bug, but I found that if you set a breakpoint<br/>&gt;&gt; on<br/>&gt;&gt; a line where a &#39;use&#39; statement exists, the breakpoint will show as set and<br/>&gt;&gt; the debugger won&#39;t complain:<br/>&gt;&gt; $ perl -d breakpoint-bug.pl<br/>&gt;&gt; Loading DB routines from perl5db.pl version 1.32<br/>&gt;&gt; Editor support available.<br/>&gt;&gt; Enter h or `h h&#39; for help, or `man perldebug&#39; for more help.<br/>&gt;&gt; main::(breakpoint-bug.pl:7):<br/>&gt;&gt; 7: print &quot;hello!\n&quot;;<br/>&gt;&gt; DB&lt;1&gt; b 9<br/>&gt;&gt; DB&lt;2&gt; v<br/>&gt;&gt; 4: use strict;<br/>&gt;&gt; 5: use warnings;<br/>&gt;&gt; 6<br/>&gt;&gt; 7==&gt; print &quot;hello!\n&quot;;<br/>&gt;&gt; 8<br/>&gt;&gt; 9:b use Data::Dumper;<br/>&gt;&gt; 10<br/>&gt;&gt; 11: print &quot;goodbye!\n&quot;;<br/>&gt;&gt; 12<br/>&gt;&gt; 13: exit 0;<br/>&gt;&gt; DB&lt;2&gt;<br/>&gt;&gt; But, if you &#39;c&#39; from line 7, you skip over the breakpoint on 9 as if it<br/>&gt;&gt; wasn&#39;t there. It isn&#39;t a huge problem (and I really should keep all of my<br/>&gt;&gt; &#39;use&#39; statements at the beginning of the script), but I figured it was<br/>&gt;&gt; worth<br/>&gt;&gt; a mention.<br/>&gt;&gt; I couldn&#39;t figure out how to actually file a bug at http://rt.perl.organd<br/>&gt;&gt; http://search.cpan.org/~jesse/perl-5.14.0/lib/perl5db.pl didn&#39;t have the<br/>&gt;&gt; usual &#39;View/Report Bugs&#39; that most modules have. I&#39;m happy to file a bug<br/>&gt;&gt; if<br/>&gt;&gt; someone could point me in the right direction.<br/>&gt;&gt; -Conor<br/>&gt;<br/>&gt;<br/>&gt; I just looked at this. I don&#39;t think there is a bug here.<br/>&gt;<br/>&gt; The code has a &quot;use&quot; statement. A breakpoint is set on that which the<br/>&gt; reporter doesn&#39;t feel is respected.<br/>&gt; However, recall that &quot;use&quot; happens at compile time and this occurs before<br/>&gt; the first stop you see in the debugger.<br/>&gt;<br/>&gt; To verify this when I issued:<br/>&gt; $Data::Dumper::VERSION from Devel::Trepan stopped at line 7, I got a<br/>&gt; version string, e.g. &#39;2.124&#39;. (in perl5db use &quot;p $Data::Dumper::VERSION&quot;<br/>&gt;<br/>&gt; Change the &quot;use&quot; to a &quot;require&quot; which then changes the semantics, and<br/>&gt; you&#39;ll things will work as you seem to expect it to would above.<br/>&gt;<br/>&gt; So in sum, I don&#39;t think there is a bug. Just perhaps confusion about how<br/>&gt; execution works -- which I admit is confusing.<br/>&gt;<br/>&gt;<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2011/12/msg149.html Wed, 21 Dec 2011 00:53:00 +0000 Re: breakpoint bug in the debugger by Rocky Bernstein A while back on Tue, 31 May 2011 18:20:51 -0700 Conor wrote:<br/><br/>Not exactly a high priority bug, but I found that if you set a breakpoint on<br/>&gt; a line where a &#39;use&#39; statement exists, the breakpoint will show as set and<br/>&gt; the debugger won&#39;t complain:<br/>&gt; $ perl -d breakpoint-bug.pl<br/>&gt; Loading DB routines from perl5db.pl version 1.32<br/>&gt; Editor support available.<br/>&gt; Enter h or `h h&#39; for help, or `man perldebug&#39; for more help.<br/>&gt; main::(breakpoint-bug.pl:7):<br/>&gt; 7: print &quot;hello!\n&quot;;<br/>&gt; DB&lt;1&gt; b 9<br/>&gt; DB&lt;2&gt; v<br/>&gt; 4: use strict;<br/>&gt; 5: use warnings;<br/>&gt; 6<br/>&gt; 7==&gt; print &quot;hello!\n&quot;;<br/>&gt; 8<br/>&gt; 9:b use Data::Dumper;<br/>&gt; 10<br/>&gt; 11: print &quot;goodbye!\n&quot;;<br/>&gt; 12<br/>&gt; 13: exit 0;<br/>&gt; DB&lt;2&gt;<br/>&gt; But, if you &#39;c&#39; from line 7, you skip over the breakpoint on 9 as if it<br/>&gt; wasn&#39;t there. It isn&#39;t a huge problem (and I really should keep all of my<br/>&gt; &#39;use&#39; statements at the beginning of the script), but I figured it was<br/>&gt; worth<br/>&gt; a mention.<br/>&gt; I couldn&#39;t figure out how to actually file a bug at http://rt.perl.org and<br/>&gt; http://search.cpan.org/~jesse/perl-5.14.0/lib/perl5db.pl didn&#39;t have the<br/>&gt; usual &#39;View/Report Bugs&#39; that most modules have. I&#39;m happy to file a bug if<br/>&gt; someone could point me in the right direction.<br/>&gt; -Conor<br/><br/><br/>I just looked at this. I don&#39;t think there is a bug here.<br/><br/>The code has a &quot;use&quot; statement. A breakpoint is set on that which the<br/>reporter doesn&#39;t feel is respected.<br/>However, recall that &quot;use&quot; happens at compile time and this occurs before<br/>the first stop you see in the debugger.<br/><br/>To verify this when I issued:<br/>$Data::Dumper::VERSION from Devel::Trepan stopped at line 7, I got a<br/>version string, e.g. &#39;2.124&#39;. (in perl5db use &quot;p $Data::Dumper::VERSION&quot;<br/><br/>Change the &quot;use&quot; to a &quot;require&quot; which then changes the semantics, and<br/>you&#39;ll things will work as you seem to expect it to would above.<br/><br/>So in sum, I don&#39;t think there is a bug. Just perhaps confusion about how<br/>execution works -- which I admit is confusing.<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2011/12/msg148.html Sun, 18 Dec 2011 21:21:06 +0000 RFC Devel::Trepan by Rocky Bernstein With the recent release of Devel::Trepan (0.1.4), I am at a juncture of<br/>next steps. So I thought I would solicit feedback.<br/><br/>The good news from my standpoint is that things are good enough for my<br/>needs. And I can be picky. Devel::Trepan has been tested on a number of<br/>Unix platforms thanks to CPANTS. And I have tested it on Windows under<br/>cygwin, Strawberry and ActiveState Perl. Of course this doesn&#39;t mean there<br/>is not much that *could* be improved.<br/><br/>Originally I had included support to go into an interactive psh shell; that<br/>required some monkey-patching of psh. I have request the change get added<br/>to psh with no motion or acknowledgement so far. Since psh development<br/>seems to be stalled, I&#39;ve since removed that support. Instead Devel::REPL<br/>which seems much better suited. The down side of Devel::REPL is that it<br/>pulls in a huge set of other packages, starting with Moose. So to do this,<br/>it would be done in a separate add-on package.<br/><br/>Speaking of splitting things off as a separate package...<br/><br/>Devel::Trepan itself is large and could be split in two possibly with<br/>benefit. Part of the effort of writing Devel::Trepan included modularizing<br/>and modernizing the DB package a little. So that could be split off. Right<br/>now one require&#39;s or use&#39;s Devel::Trepan::DB. But due to Perl&#39;s debugger<br/>requirements, it works in the DB namespace.<br/><br/>Devel::Trepan::DB would not be a total replacement for perl5db.pl. However<br/>if a command part were written, then it could be. The command part I think<br/>could be fairly lean.<br/><br/>Another direction to move is going backward to allow support for Perl<br/>before version 5.10.0. The current code does not fundamentally need 5.10.0.<br/>Although I used features from 5.10 like &#39;state&#39; and &#39;switch&#39; and //=<br/>assignment, the code could be rewritten without that making it a little bit<br/>uglier. But I wonder how widespread perl 5.8.x is.<br/><br/>And going in the opposite direction, I could start patching Perl to add two<br/>features that I think would help debugging. The first change is to add some<br/>sort of eval_n where one can eval in the context of a prior call frame.<br/>This is would not only obviate the use of Eval::StackTrace::WithLexicals,<br/>Devel::StrackTrace::WithLexicals, Peek, and the PadWalker packages but<br/>would handle &quot;local&quot; variables. So it would be more reliable. Equally<br/>important is that the structure of the debugger could become less<br/>convoluted.<br/><br/>The other small change would be add to caller() a number indicating the<br/>Perl5 Node that is currently under execution. This number can then be used<br/>to disambiguate the various places one can be when one is stopped in a<br/>given line. I believe this is a pretty simple change to make, but it would<br/>mean a change to Perl5 and therefore might take a while, depending on when<br/>the next release is scheduled.<br/><br/>Other miscellaneous items:<br/><br/>- adding history save/restore. Term::ReadLine::Perl doesn&#39;t have<br/> StifleHistory and ReadHistory. Perhaps the way to go would be to<br/> add those to Term::ReadLine::Perl<br/><br/>- Add gdb-like signal handling routines &quot;handle&quot;.<br/><br/>- Making restart better by saving and restoring debugger state.<br/><br/>- More remote debugging features.<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2011/12/msg147.html Sun, 18 Dec 2011 08:42:29 +0000 accelerated stepping from a old thread and Perl changes. by Rocky Bernstein I was looking at old debugger list postings on &quot;accelerated stepping&quot;.<br/><br/>The general problem of how to make stepping feel right is a well trodden<br/>topic. So let me describe how the trepanning debuggers such as<br/>Devel::Trepan partially address this. The idea builds on something Kent<br/>Sibilev added to ruby-debug, and as far as I know he was the first to do<br/>this.<br/><br/>There is a setting called &quot;set different&quot; in ruby-debug (originally called<br/>&quot;set force&quot;) which can be &quot;on&quot; or &quot;off&quot;. When &quot;on&quot; the setting causes<br/>&quot;next&quot; and &quot;step&quot; commands to stop at a different line numbers for a given<br/>frame. The stack frame is used because one wants to treat recursive calls<br/>as &quot;different&quot;. In the trepanning debuggers, I added &quot;+&quot; and &quot;-&quot; suffixes<br/>to the &quot;step&quot; and &quot;next&quot; commands which over-ride the default setting.<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2011/12/msg146.html Sat, 03 Dec 2011 11:12:27 +0000 Re: PadWalker, eval and perl5db by Rocky Bernstein On Wed, Nov 23, 2011 at 8:06 AM, Brock &lt;awwaiid@thelackthereof.org&gt; wrote:<br/><br/>&gt; On Sun, 20 Nov 2011 Rocky Bernstein wrote:<br/>&gt; &gt; I&#39;ve briefly looked at PadWalker which can look at &quot;my&quot; and &quot;our&quot;<br/>&gt; &gt; variables on a call stack. And while this is very useful, it is not<br/>&gt; &gt; the same as being able to evaluate a string in the context of a stack<br/>&gt; &gt; frame.<br/>&gt; &gt;<br/>&gt; &gt; Has anyone tried to create such an eval? A simple suggested interface<br/>&gt; &gt; would be to pass it an integer which indicates the call stack frame to<br/>&gt; &gt; use.<br/>&gt;<br/>&gt; You might take a look at Eval::WithLexicals and how it is used in<br/>&gt; Plack::Middleware::InteractiveDebugger (which, upon die(), lets the user<br/>&gt; open a web-based REPL at any level of the call stack). Looks like there<br/>&gt; is some manual work you have to do though.<br/>&gt;<br/><br/>Thanks! I think I now understand how it&#39;s done. Sort of.<br/><br/>Devel::StrackTrace::WithLexicals uses PadWalker to create a hash of of all<br/>the lexical variables for a given call frame. Eval::WithLexicals is then<br/>passed that hash. By the way, this is similar to how Python&#39;s eval works.<br/><br/>And then comes the complicated part, Eval::WithLexicals uses that hash<br/>somehow in a string eval. How this works is not obvious to me, but the next<br/>couple of days I&#39;ll probably figure this out as I have a good debugger<br/>that can track nicely through string evals which is used a bit here.<br/>Eval::WithLexicals (and Eval::WithLexicals::WithHintPersistence ) then<br/>needs to put changed values back someplace. (Perhaps this id done via<br/>B::svref_2object.)<br/><br/>So one thing that needs to be checked in my use is that the values do<br/>indeed get put back into the right place in the call stack and not just say<br/>in the hash created by Devel::StackTrace::WithLexicals.<br/><br/>Another thing that seems to be something that could go wrong is in handling<br/>local variables, because PadWaker doesn&#39;t handle local variables.<br/><br/>Suppose I have a local variable $a defined in main and a couple of calls<br/>down I have another local $a --alsi in package main::. I am not sure how I<br/>would be able to access the outer or main-most $a to read the value.<br/><br/>(Actually here is a bad way and one that is sort of used in the first Ruby<br/>debugger: On every call create a closure with all of the values. This is<br/>horrendously slow.)<br/><br/>And looking at WithLexical.pm&#39;s code, there is this comment in<br/>_record_caller_data():<br/> # PadWalker ignores eval block and eval string so we must do so too.<br/><br/>So this could also be another source of discrepancy people may run into.<br/><br/>Given all of this -- and I am sorry if this was a bit long -- it seems that<br/>life would be much simpler and more reliable if Perl just had a eval_n<br/>function which did the evaluations n levels down the call stack.<br/><br/>Looking at the C code, one can get a PERL_CONTEXT from the call stack and<br/>somehow one just needs to make sure that this is what is used by this new<br/>eval_n routine.<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2011/11/msg145.html Wed, 23 Nov 2011 22:37:35 +0000 RE: PadWalker, eval and perl5db by Brock On Sun, 20 Nov 2011 Rocky Bernstein wrote:<br/>&gt; I&#39;ve briefly looked at PadWalker which can look at &quot;my&quot; and &quot;our&quot;<br/>&gt; variables on a call stack. And while this is very useful, it is not<br/>&gt; the same as being able to evaluate a string in the context of a stack<br/>&gt; frame.<br/>&gt;<br/>&gt; Has anyone tried to create such an eval? A simple suggested interface<br/>&gt; would be to pass it an integer which indicates the call stack frame to<br/>&gt; use.<br/><br/>You might take a look at Eval::WithLexicals and how it is used in<br/>Plack::Middleware::InteractiveDebugger (which, upon die(), lets the user<br/>open a web-based REPL at any level of the call stack). Looks like there<br/>is some manual work you have to do though.<br/><br/>--Brock<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2011/11/msg144.html Wed, 23 Nov 2011 05:07:31 +0000 PadWalker, eval and perl5db by Rocky Bernstein In working on the Trepanning debugger for Perl which in large part is<br/>modernizing and modularizing perl5db, I keep running into the limitations<br/>of eval.<br/><br/>In both Ruby and Python, one can pass arguments in addition to the string<br/>to evaluate which controls the environment or context that evaluation uses.<br/><br/>Lacking this, evaluations in perl5db need to be done in the DB namespace -<br/>but inside the &quot;eval&quot;, one must first switch back to the debugged program<br/>namespace, e.g. &quot;main&quot;.<br/><br/>Consider what this does in debuggers that want to modularize code and move<br/>code and modules out of the DB namespace. In the trepanning debugger there<br/>is an object which is the command processor. It is pretty much a<br/>self-contained read-eval-print loop. But the eval part of it has to go back<br/>to DB any time an evaluation needs to be done. So some mechanism needed to<br/>ping-pong values back and forth between the command loop and DB.<br/><br/>Another limitation of the Perl debuggers is that they can only evaluate<br/>expressions which may contain &quot;my&quot; variables in the context of the point of<br/>the stopped program, not call-stack frames further down.<br/><br/>I&#39;ve briefly looked at PadWalker which can look at &quot;my&quot; and &quot;our&quot; variables<br/>on a call stack. And while this is very useful, it is not the same as being<br/>able to evaluate a string in the context of a stack frame.<br/><br/>Has anyone tried to create such an eval? A simple suggested interface would<br/>be to pass it an integer which indicates the call stack frame to use.<br/><br/>Thanks.<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2011/11/msg143.html Sun, 20 Nov 2011 21:41:05 +0000 Post announcement of new debugger Devel::Trepan by Rocky Bernstein As Shrek says when he first entered Duloc: ``It&#39;s quiet here... Too quiet!&#39;&#39;<br/><br/>A little while ago I asked if there was a way get get some sort of object<br/>which indicates the exact position from caller. Again, line number doesn&#39;t<br/>really cut it since there can be many statements on a line.<br/><br/>I just ran across this very amusing blog:<br/> http://funcall.blogspot.com/2011/03/tail-recursion-and-debugging.html<br/><br/>As a result, in a couple of the Ruby trepanning debuggers I now detect<br/>immediate recursion and instead of repeating those lines over and over<br/>again I give a count of the repetitions. (I still should handle indirect<br/>recursions.)<br/><br/>More generally, it would be nice if the various packages that print stack<br/>traces as well as those inside Perl core detect recursion and try to reduce<br/>duplication of long traces by giving such summary information.<br/><br/>However in order to do this one really does need a more precise location<br/>than that which caller gives. I could give an example here of how line<br/>number isn&#39;t precise, but I suspect you all get the idea.<br/><br/>- - - -<br/><br/>Last, in the interest of creating more noise. Let me say I&#39;ve now put on<br/>CPAN the first version of Devel::Trepan. As before, there is still an awful<br/>lot that could be done and I think is straightforward to add.<br/><br/>The release is good enough for me to use, and I tend to be a little bit<br/>more fussy than most when it comes to debugging. The amount of additional<br/>work I put on this will probably be determined by interest and my needs.<br/><br/>So in closing I&#39;ll mention a couple more interesting and unique things in<br/>this debugger.<br/><br/>* POSIX style set -x tracing. On occasion people tell me that they don&#39;t<br/>want a debugger all they want is POSIX-style tracing. So that&#39;s there now.<br/>You have this turned on from the start and not enter the debugger or you<br/>can turn it on inside the debugger and then run &quot;continue&quot;.<br/><br/>* In passing I previously mention in the last post command aliases. For<br/>complicated things one can create a macro which is simply an anonymous Perl<br/>subroutine. Simple, powerful and Perl!<br/><br/>* There is a settings &quot;set timer on&quot; which will tell you the elapsed time<br/>between debugger entry. I have used that in the past to give me a feel for<br/>the difference in speed between &quot;step over&quot;, &quot;finish&quot; and &quot;continue&quot;, but<br/>one could also use it to measure the time the debugged program takes.<br/><br/>* Entering Psh. In Python and Ruby folks typically want to enter a shell<br/>rather than have to work within the confines of the debugger shell. If you<br/>want to enter Psh inside the debugger you can. If there are other shells,<br/>especially ones that allow themselves to be embedded, I don&#39;t mind adding<br/>more. In fact, I had to monkey patch Psh to get it to embed. The one<br/>caveat with going into a shell is the name scoping problem. You generally<br/>don&#39;t see &quot;my&quot; variables. However inside the debugger whenever you evaluate<br/>an expression it gets saved in the global @DB::D array. So inside the<br/>debugger before entering Psh one could evaluate variables that you might<br/>want to use.<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2011/10/msg142.html Sat, 29 Oct 2011 11:40:37 +0000 Re: Pre announcement of yet another Perl debugger by Reini Urban You are a hero. Much appreciated. I&#39;ll look into adding the SMOP.<br/> On Sep 25, 2011 11:22 PM, &quot;Rocky Bernstein&quot; &lt;rocky.bernstein@gmail.com&gt;<br/>wrote:<br/>&gt; With much trepidation, recently I started porting my trepanning debugger<br/>to<br/>&gt; Perl.<br/>&gt; Perl has always had a really good debugger, so said above, I undertook<br/>this<br/>&gt; with some hesitation.<br/>&gt;<br/>&gt; As someone who doesn&#39;t always work in Perl, the stock Perl debugger,<br/>&gt; perl5db.pl has always felt to me a little bit of a one off.<br/>&gt;<br/>&gt; For example, I can&#39;t think of another debugger that uses T to show a<br/>&gt; backtrace, and backtraces in debuggers usually include the point where one<br/>&gt; is stopped. The fact that there are no frame switching commands (in gdb:<br/>&gt; &quot;up&quot;, &quot;down&quot;, and &quot;frame&quot;) may be related to the fact that evaluation in<br/>&gt; Perl&#39;s debugger works only on the top-most frame. But even given this, I<br/>&gt; think this not having frame switching commands is a misguided decision<br/>since<br/>&gt; frame switching is also useful for things like setting breakpoints or<br/>&gt; listing code.<br/>&gt;<br/>&gt; So one motivation for writing a debugger (or rewriting per5db or porting<br/>the<br/>&gt; Ruby trepanning debugger - take your pick) was to provide more gdb-like<br/>&gt; commands. Another goal was to have something a little more modular and<br/>&gt; testable. And a third was to provide some of the things I think are cool<br/>in<br/>&gt; the trepanning debugger that I think are lacking in perl5db.<br/>&gt;<br/>&gt; Although the work is far from complete, already there are things in there<br/>I<br/>&gt; think cool. For example code is syntax highlighted<br/>&gt; via Syntax::Highlight::Perl::Improved. (I haven&#39;t put in the &quot;list&quot;<br/>command<br/>&gt; though.) There is Readline debugger command completion. One of the cool<br/>&gt; kinds of completion is on the &quot;eval&quot; command where the current line of<br/>&gt; source will be filled in. There is an eval? command which I&#39;ve found<br/>useful<br/>&gt; in stripping off common expression parts of a statement. For example eval?<br/>&gt; of &quot;return foo(a,b,c)&quot; would be foo(a,b,c). Or eval? of &quot;my $x=foo(a,b,c)&quot;<br/>&gt; would be evaluate &quot;$x = foo(a,b,c)&quot;; eval? of &quot;if ($x &gt; 5) {&quot; would be<br/>&gt; &quot;($x &gt; 5)&quot;. And so on.<br/>&gt;<br/>&gt; When something is evaluated the return value is saved in a global array in<br/>&gt; the DB namespace.<br/>&gt;<br/>&gt; Since eval context determines how something is evaluated, there are<br/>commands<br/>&gt; for evaluating an expression either in a hash, array and scalar context.<br/>&gt; (See eval@ eval$ and eval% with command aliases @, $ and %).<br/>&gt;<br/>&gt; The way the code is currently structured, commands reside in a &quot;command&quot;<br/>&gt; directory and each command is a file/module in that directory. Given this,<br/>&gt; it&#39;s possible for users to add their own commands in a user command<br/>&gt; directory. And although I don&#39;t intend on doing this, it would be possible<br/>&gt; to just redo the existing perl5db commands using the Trepanning command<br/>&gt; framework. The advantage here is that commands would be included in<br/>command<br/>&gt; completion and documented in the help system. Oh, did I mention that<br/>rather<br/>&gt; extensive help is available for each command, and that you can list<br/>&gt; categories of commands as is done in gdb?<br/>&gt;<br/>&gt; Ok. Enough advertising. The code resides on github right now in<br/>&gt; https://github.com/rocky/Perl-Devel-Trepan. It&#39;ll make its way to CPAN as<br/>a<br/>&gt; package at some point. There are still a number of things to add before<br/>&gt; general release, but so far what needs adding is just SMOP (small matter<br/>of<br/>&gt; programming): code and tests to be ported from the Ruby trepanning<br/>debugger<br/>&gt; or adapted from perl5db.<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2011/09/msg141.html Tue, 27 Sep 2011 06:16:32 +0000 Re: Pre announcement of yet another Perl debugger by Rocky Bernstein On Mon, Sep 26, 2011 at 12:49 PM, Reini Urban &lt;rurban@x-ray.at&gt; wrote:<br/><br/>&gt; You are a hero.<br/>&gt;<br/><br/>Thanks for the kind words, but, no, really you guys are. Coming back to Perl<br/>from Ruby (via Python) I have come to appreciate how much of the greatness<br/>of Ruby was in fact there in Perl. (Example: in Perl, like Ruby but as<br/>opposed to Python one can &quot;reopen&quot; classes not just by eval&#39;ing strings but<br/>also by having the same packages named in many files. And on the other hand<br/>one can put many packages inside a single file. All of this facilitates<br/>aspect-oriented programming.)<br/><br/>&gt; Much appreciated. I&#39;ll look into adding the SMOP.<br/>&gt;<br/><br/>I would really appreciate that. My Perl style still has a bit to be desired<br/>and I am sure the command code could be DRY&#39;d (Do not Repeat Yourself) a lot<br/>more.<br/><br/>In reviewing the current state of debuggers in Perl, I was looking at the<br/>B-Debugger. At run-time, is there a way one can figure out exactly where one<br/>is in the parse or evaluation tree? I think it would be neat to be able to<br/>report, on demand, where one is evaluation tree. Because that is much more<br/>precise than a file and line number where, among other things, there can be<br/>many statements on a single line.<br/><br/>On Sep 25, 2011 11:22 PM, &quot;Rocky Bernstein&quot; &lt;rocky.bernstein@gmail.com&gt;<br/>wrote:<br/><br/>&gt; &gt; With much trepidation, recently I started porting my trepanning debugger<br/>&gt; to<br/>&gt; &gt; Perl.<br/>&gt; &gt; Perl has always had a really good debugger, so said above, I undertook<br/>&gt; this<br/>&gt; &gt; with some hesitation.<br/>&gt; &gt;<br/>&gt; &gt; As someone who doesn&#39;t always work in Perl, the stock Perl debugger,<br/>&gt; &gt; perl5db.pl has always felt to me a little bit of a one off.<br/>&gt; &gt;<br/>&gt; &gt; For example, I can&#39;t think of another debugger that uses T to show a<br/>&gt; &gt; backtrace, and backtraces in debuggers usually include the point where<br/>&gt; one<br/>&gt; &gt; is stopped. The fact that there are no frame switching commands (in gdb:<br/>&gt; &gt; &quot;up&quot;, &quot;down&quot;, and &quot;frame&quot;) may be related to the fact that evaluation in<br/>&gt; &gt; Perl&#39;s debugger works only on the top-most frame. But even given this, I<br/>&gt; &gt; think this not having frame switching commands is a misguided decision<br/>&gt; since<br/>&gt; &gt; frame switching is also useful for things like setting breakpoints or<br/>&gt; &gt; listing code.<br/>&gt; &gt;<br/>&gt; &gt; So one motivation for writing a debugger (or rewriting per5db or porting<br/>&gt; the<br/>&gt; &gt; Ruby trepanning debugger - take your pick) was to provide more gdb-like<br/>&gt; &gt; commands. Another goal was to have something a little more modular and<br/>&gt; &gt; testable. And a third was to provide some of the things I think are cool<br/>&gt; in<br/>&gt; &gt; the trepanning debugger that I think are lacking in perl5db.<br/>&gt; &gt;<br/>&gt; &gt; Although the work is far from complete, already there are things in there<br/>&gt; I<br/>&gt; &gt; think cool. For example code is syntax highlighted<br/>&gt; &gt; via Syntax::Highlight::Perl::Improved. (I haven&#39;t put in the &quot;list&quot;<br/>&gt; command<br/>&gt; &gt; though.) There is Readline debugger command completion. One of the cool<br/>&gt; &gt; kinds of completion is on the &quot;eval&quot; command where the current line of<br/>&gt; &gt; source will be filled in. There is an eval? command which I&#39;ve found<br/>&gt; useful<br/>&gt; &gt; in stripping off common expression parts of a statement. For example<br/>&gt; eval?<br/>&gt; &gt; of &quot;return foo(a,b,c)&quot; would be foo(a,b,c). Or eval? of &quot;my<br/>&gt; $x=foo(a,b,c)&quot;<br/>&gt; &gt; would be evaluate &quot;$x = foo(a,b,c)&quot;; eval? of &quot;if ($x &gt; 5) {&quot; would be<br/>&gt; &gt; &quot;($x &gt; 5)&quot;. And so on.<br/>&gt; &gt;<br/>&gt; &gt; When something is evaluated the return value is saved in a global array<br/>&gt; in<br/>&gt; &gt; the DB namespace.<br/>&gt; &gt;<br/>&gt; &gt; Since eval context determines how something is evaluated, there are<br/>&gt; commands<br/>&gt; &gt; for evaluating an expression either in a hash, array and scalar context.<br/>&gt; &gt; (See eval@ eval$ and eval% with command aliases @, $ and %).<br/>&gt; &gt;<br/>&gt; &gt; The way the code is currently structured, commands reside in a &quot;command&quot;<br/>&gt; &gt; directory and each command is a file/module in that directory. Given<br/>&gt; this,<br/>&gt; &gt; it&#39;s possible for users to add their own commands in a user command<br/>&gt; &gt; directory. And although I don&#39;t intend on doing this, it would be<br/>&gt; possible<br/>&gt; &gt; to just redo the existing perl5db commands using the Trepanning command<br/>&gt; &gt; framework. The advantage here is that commands would be included in<br/>&gt; command<br/>&gt; &gt; completion and documented in the help system. Oh, did I mention that<br/>&gt; rather<br/>&gt; &gt; extensive help is available for each command, and that you can list<br/>&gt; &gt; categories of commands as is done in gdb?<br/>&gt; &gt;<br/>&gt; &gt; Ok. Enough advertising. The code resides on github right now in<br/>&gt; &gt; https://github.com/rocky/Perl-Devel-Trepan. It&#39;ll make its way to CPAN<br/>&gt; as a<br/>&gt; &gt; package at some point. There are still a number of things to add before<br/>&gt; &gt; general release, but so far what needs adding is just SMOP (small matter<br/>&gt; of<br/>&gt; &gt; programming): code and tests to be ported from the Ruby trepanning<br/>&gt; debugger<br/>&gt; &gt; or adapted from perl5db.<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2011/09/msg140.html Mon, 26 Sep 2011 17:48:04 +0000 Pre announcement of yet another Perl debugger by Rocky Bernstein With much trepidation, recently I started porting my trepanning debugger to<br/>Perl.<br/>Perl has always had a really good debugger, so said above, I undertook this<br/>with some hesitation.<br/><br/>As someone who doesn&#39;t always work in Perl, the stock Perl debugger,<br/>perl5db.pl has always felt to me a little bit of a one off.<br/><br/>For example, I can&#39;t think of another debugger that uses T to show a<br/>backtrace, and backtraces in debuggers usually include the point where one<br/>is stopped. The fact that there are no frame switching commands (in gdb:<br/>&quot;up&quot;, &quot;down&quot;, and &quot;frame&quot;) may be related to the fact that evaluation in<br/>Perl&#39;s debugger works only on the top-most frame. But even given this, I<br/>think this not having frame switching commands is a misguided decision since<br/>frame switching is also useful for things like setting breakpoints or<br/>listing code.<br/><br/>So one motivation for writing a debugger (or rewriting per5db or porting the<br/>Ruby trepanning debugger - take your pick) was to provide more gdb-like<br/>commands. Another goal was to have something a little more modular and<br/>testable. And a third was to provide some of the things I think are cool in<br/>the trepanning debugger that I think are lacking in perl5db.<br/><br/>Although the work is far from complete, already there are things in there I<br/>think cool. For example code is syntax highlighted<br/>via Syntax::Highlight::Perl::Improved. (I haven&#39;t put in the &quot;list&quot; command<br/>though.) There is Readline debugger command completion. One of the cool<br/>kinds of completion is on the &quot;eval&quot; command where the current line of<br/>source will be filled in. There is an eval? command which I&#39;ve found useful<br/>in stripping off common expression parts of a statement. For example eval?<br/>of &quot;return foo(a,b,c)&quot; would be foo(a,b,c). Or eval? of &quot;my $x=foo(a,b,c)&quot;<br/>would be evaluate &quot;$x = foo(a,b,c)&quot;; eval? of &quot;if ($x &gt; 5) {&quot; would be<br/>&quot;($x &gt; 5)&quot;. And so on.<br/><br/>When something is evaluated the return value is saved in a global array in<br/>the DB namespace.<br/><br/>Since eval context determines how something is evaluated, there are commands<br/>for evaluating an expression either in a hash, array and scalar context.<br/>(See eval@ eval$ and eval% with command aliases @, $ and %).<br/><br/>The way the code is currently structured, commands reside in a &quot;command&quot;<br/>directory and each command is a file/module in that directory. Given this,<br/>it&#39;s possible for users to add their own commands in a user command<br/>directory. And although I don&#39;t intend on doing this, it would be possible<br/>to just redo the existing perl5db commands using the Trepanning command<br/>framework. The advantage here is that commands would be included in command<br/>completion and documented in the help system. Oh, did I mention that rather<br/>extensive help is available for each command, and that you can list<br/>categories of commands as is done in gdb?<br/><br/>Ok. Enough advertising. The code resides on github right now in<br/>https://github.com/rocky/Perl-Devel-Trepan. It&#39;ll make its way to CPAN as a<br/>package at some point. There are still a number of things to add before<br/>general release, but so far what needs adding is just SMOP (small matter of<br/>programming): code and tests to be ported from the Ruby trepanning debugger<br/>or adapted from perl5db.<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2011/09/msg139.html Sun, 25 Sep 2011 21:22:01 +0000 Re: breakpoint bug in the debugger by andreas.koenig.7os6VVqR &gt;&gt;&gt;&gt;&gt; On Tue, 31 May 2011 18:20:32 -0700, Conor &lt;conor.list@gmail.com&gt; said:<br/><br/> &gt; I couldn&#39;t figure out how to actually file a bug at http://rt.perl.org and<br/> &gt; http://search.cpan.org/~jesse/perl-5.14.0/lib/perl5db.pl didn&#39;t have the<br/> &gt; usual &#39;View/Report Bugs&#39; that most modules have. I&#39;m happy to file a bug if<br/> &gt; someone could point me in the right direction.<br/><br/>You type perlbug in your console and answer the questions. It will send<br/>a mail in the end.<br/><br/>-- <br/>andreas<br/> http://www.nntp.perl.org/group/perl.debugger/2011/06/msg138.html Fri, 03 Jun 2011 23:11:14 +0000 breakpoint bug in the debugger by Conor http://www.nntp.perl.org/group/perl.debugger/2011/05/msg137.html Tue, 31 May 2011 18:20:42 +0000 Fwd: perl debugger+taint mode issue in 5.10.0, 5.10.1 5.12.1, no issue in 5.8.8 by swamy sangamesh Hi All,<br/><br/>Looks like this is happening if we have two BEGIN blocks and glob() is<br/>called.<br/>No issue is seen if we have only one BEGIN block.<br/><br/><br/>---------- Forwarded message ----------<br/>From: swamy sangamesh &lt;swamy.sangamesh@gmail.com&gt;<br/>Date: Tue, Aug 3, 2010 at 4:59 PM<br/>Subject: perl debugger+taint mode issue in 5.10.0, 5.10.1 5.12.1, no issue<br/>in 5.8.8<br/>To: perl5-porters@perl.org, debugger@perl.org<br/><br/><br/><br/>Hi All,<br/><br/>I got the scenario where perl debugger with taint mode is failing.<br/>I am using below .pm amd .xs file for testing<br/><br/>$ cat *Mytest.pm*<br/>#!/usr/bin/perl -wT<br/>package Mytest;<br/>use XSLoader ();<br/><br/>BEGIN {<br/> XSLoader::load(&#39;Mytest&#39;);<br/>}<br/>BEGIN {<br/> XSLoader::load(&#39;Mytest&#39;);<br/> my $var = defined($0)? UNDEFINE : 1;<br/>}<br/><br/>sub func_test {<br/> glob(&quot;check&quot;);<br/> return 1;<br/>}<br/><br/>1;<br/><br/><br/>$ cat *Mytest.xs*<br/>#include &quot;EXTERN.h&quot;<br/>#include &quot;perl.h&quot;<br/>#include &quot;XSUB.h&quot;<br/><br/>#include &quot;ppport.h&quot;<br/>#define UNDEFINE 0<br/><br/>MODULE = Mytest PACKAGE = Mytest<br/><br/>IV<br/>UNDEFINE()<br/> ALIAS:<br/> UNDEFINE = 0<br/> CODE:<br/> switch(ix) {<br/> case 0: RETVAL = UNDEFINE; break;<br/> }<br/> OUTPUT:<br/> RETVAL<br/><br/>when i issue perl -dT Mytest.pm getting insecure dependency error.<br/><br/>$ *perl -dT Mytest.pm*<br/><br/>Loading DB routines from perl5db.pl version 1.3<br/>Editor support available.<br/><br/>Enter h or `h h&#39; for help, or `man perldebug&#39; for more help.<br/><br/>*Insecure dependency in eval while running with -T switch at<br/>/usr/lib/perl5/5.10.0/i386-linux-thread-multi/File/Glob.pm line 92*.<br/>Compilation failed in require at Mytest.pm line 34.<br/> at Mytest.pm line 34<br/> Mytest::BEGIN() called at<br/>/usr/lib/perl5/5.10.0/i386-linux-thread-multi/File/Glob.pm line 34<br/> eval {...} called at<br/>/usr/lib/perl5/5.10.0/i386-linux-thread-multi/File/Glob.pm line 34<br/>BEGIN failed--compilation aborted at Mytest.pm line 34.<br/> at Mytest.pm line 34<br/>Debugged program terminated. Use q to quit or R to restart,<br/> use o inhibit_exit to avoid stopping after program termination,<br/> h q, h R or h o to get additional info.<br/> DB&lt;1&gt;<br/><br/><br/>I checked *perl-5.10.0, 5.10.1 and 5.12.1*, issue exists in these release<br/>and seems to be common in all platfrom, as i tested it in aix and linux.<br/>Not seeing any error message in perl-5.8.8. Not sure about 5.9 releases.<br/><br/>Is this a regression which caused this issue? i thought<br/>http://rt.perl.org/rt3/Ticket/Display.html?id=39733 might have caused this<br/>But testing after backing out the changes also got same error.<br/>Please let me know your suggestions.<br/>-- <br/>Thanks &amp; Regards,<br/>Sangamesh<br/><br/><br/><br/><br/>-- <br/>Thanks &amp; Regards,<br/>Sangamesh<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2010/08/msg136.html Thu, 05 Aug 2010 04:52:31 +0000 perl debugger+taint mode issue in 5.10.0, 5.10.1 5.12.1, no issue in 5.8.8 by swamy sangamesh Hi All,<br/><br/>I got the scenario where perl debugger with taint mode is failing.<br/>I am using below .pm amd .xs file for testing<br/><br/>$ cat *Mytest.pm*<br/>#!/usr/bin/perl -wT<br/>package Mytest;<br/>use XSLoader ();<br/><br/>BEGIN {<br/> XSLoader::load(&#39;Mytest&#39;);<br/>}<br/>BEGIN {<br/> XSLoader::load(&#39;Mytest&#39;);<br/> my $var = defined($0)? UNDEFINE : 1;<br/>}<br/><br/>sub func_test {<br/> glob(&quot;check&quot;);<br/> return 1;<br/>}<br/><br/>1;<br/><br/><br/>$ cat *Mytest.xs*<br/>#include &quot;EXTERN.h&quot;<br/>#include &quot;perl.h&quot;<br/>#include &quot;XSUB.h&quot;<br/><br/>#include &quot;ppport.h&quot;<br/>#define UNDEFINE 0<br/><br/>MODULE = Mytest PACKAGE = Mytest<br/><br/>IV<br/>UNDEFINE()<br/> ALIAS:<br/> UNDEFINE = 0<br/> CODE:<br/> switch(ix) {<br/> case 0: RETVAL = UNDEFINE; break;<br/> }<br/> OUTPUT:<br/> RETVAL<br/><br/>when i issue perl -dT Mytest.pm getting insecure dependency error.<br/><br/>$ *perl -dT Mytest.pm*<br/><br/>Loading DB routines from perl5db.pl version 1.3<br/>Editor support available.<br/><br/>Enter h or `h h&#39; for help, or `man perldebug&#39; for more help.<br/><br/>*Insecure dependency in eval while running with -T switch at<br/>/usr/lib/perl5/5.10.0/i386-linux-thread-multi/File/Glob.pm line 92*.<br/>Compilation failed in require at Mytest.pm line 34.<br/> at Mytest.pm line 34<br/> Mytest::BEGIN() called at<br/>/usr/lib/perl5/5.10.0/i386-linux-thread-multi/File/Glob.pm line 34<br/> eval {...} called at<br/>/usr/lib/perl5/5.10.0/i386-linux-thread-multi/File/Glob.pm line 34<br/>BEGIN failed--compilation aborted at Mytest.pm line 34.<br/> at Mytest.pm line 34<br/>Debugged program terminated. Use q to quit or R to restart,<br/> use o inhibit_exit to avoid stopping after program termination,<br/> h q, h R or h o to get additional info.<br/> DB&lt;1&gt;<br/><br/><br/>I checked *perl-5.10.0, 5.10.1 and 5.12.1*, issue exists in these release<br/>and seems to be common in all platfrom, as i tested it in aix and linux.<br/>Not seeing any error message in perl-5.8.8. Not sure about 5.9 releases.<br/><br/>Is this a regression which caused this issue? i thought<br/>http://rt.perl.org/rt3/Ticket/Display.html?id=39733 might have caused this<br/>But testing after backing out the changes also got same error.<br/>Please let me know your suggestions.<br/>-- <br/>Thanks &amp; Regards,<br/>Sangamesh<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2010/08/msg135.html Tue, 03 Aug 2010 04:29:58 +0000 perl debugg with taint mode is not working in perl-5.10.1 by swamy sangamesh Hi All,<br/><br/>We update the perl from 5.8.8 to 5.10.1 in AIX,<br/>when we use perl debug with taint mode using -dT then we are getting<br/>following error<br/><br/>Insecure dependency in eval while running with -T switch at<br/>/usr/opt/perl5/lib/5.10.1/aix-thread-multi/File/Glob.pm line 96.<br/><br/>we are not getting any error if we use perl-5.8.8<br/><br/>Just for testing i did this change<br/><br/># diff -cr Glob.pm.bak Glob.pm<br/>*** Glob.pm.bak Sun Oct 12 00:56:58 2008<br/>--- Glob.pm Sun Oct 12 05:44:19 2008<br/>***************<br/>*** 89,94 ****<br/>--- 89,99 ----<br/> require Carp;<br/> Carp::croak($error);<br/> }<br/>+ if ($val =~ /^(\d+)$/) {<br/>+ $val = $1; # $data now untainted<br/>+ } else {<br/>+ die &quot;Bad data in &#39;$val&#39;&quot;; # log this somewhere<br/>+ }<br/> eval &quot;sub $AUTOLOAD { $val }&quot;;<br/> goto &amp;$AUTOLOAD;<br/> }<br/><br/>and debugger was able to run the command but again i got the insecure<br/>dependency error in<br/>/usr/opt/perl5/lib/5.10.1/aix-thread-multi/IO/File.pm for open call in open<br/>subroutine<br/>when used c command.<br/><br/>Has anyone come across such situation or any suggestion on workaround would<br/>be very helpful<br/><br/>-- <br/>Thanks &amp; Regards,<br/>Sangamesh<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2010/07/msg134.html Wed, 14 Jul 2010 08:11:07 +0000 Re: website update: B::Debugger by Gabor Szabo Added,<br/>with some self promotion :-)<br/><br/>Gabor<br/><br/>On Tue, Jan 19, 2010 at 11:08 AM, Richard Foley &lt;Richard.Foley@rfi.net&gt; wrote:<br/>&gt; Hi Reini,<br/>&gt;<br/>&gt; Good idea.<br/>&gt;<br/>&gt; I&#39;m forwarding this to Gabor, so he can update the site directly.<br/>&gt;<br/>&gt; Cheers.<br/>&gt;<br/>&gt; --<br/>&gt; Richard Foley<br/>&gt; Ciao - shorter than aufwiedersehen<br/>&gt;<br/>&gt; http://www.rfi.net/<br/>&gt;<br/>&gt; On Monday 18 January 2010 12:16:23 Reini Urban wrote:<br/>&gt;&gt; Hi<br/>&gt;&gt;<br/>&gt;&gt; I have a website update suggestion regarding debugging B modules.<br/>&gt;&gt;<br/>&gt;&gt; http://debugger.perl.org/tools.html<br/>&gt;&gt;<br/>&gt;&gt; &lt;h3&gt;&lt;a href=&quot;http://search.cpan.org/dist/B-Debugger/&quot;&gt;B::Debugger&lt;/h3&gt;<br/>&gt;&gt; Debug B modules and optrees.<br/>&gt;&gt;<br/>&gt;&gt; Thanks<br/>&gt;<br/>&gt;<br/>&gt;<br/> http://www.nntp.perl.org/group/perl.debugger/2010/01/msg133.html Wed, 20 Jan 2010 10:38:06 +0000 Re: website update: B::Debugger by Richard Foley Hi Reini,<br/><br/>Good idea.<br/><br/>I&#39;m forwarding this to Gabor, so he can update the site directly.<br/><br/>Cheers.<br/><br/>--<br/>Richard Foley<br/>Ciao - shorter than aufwiedersehen<br/><br/>http://www.rfi.net/<br/><br/>On Monday 18 January 2010 12:16:23 Reini Urban wrote:<br/>&gt; Hi<br/>&gt;<br/>&gt; I have a website update suggestion regarding debugging B modules.<br/>&gt;<br/>&gt; http://debugger.perl.org/tools.html<br/>&gt;<br/>&gt; &lt;h3&gt;&lt;a href=&quot;http://search.cpan.org/dist/B-Debugger/&quot;&gt;B::Debugger&lt;/h3&gt;<br/>&gt; Debug B modules and optrees.<br/>&gt;<br/>&gt; Thanks<br/><br/><br/> http://www.nntp.perl.org/group/perl.debugger/2010/01/msg132.html Tue, 19 Jan 2010 00:07:41 +0000 website update: B::Debugger by Reini Urban Hi<br/><br/>I have a website update suggestion regarding debugging B modules.<br/><br/>http://debugger.perl.org/tools.html<br/><br/>&lt;h3&gt;&lt;a href=&quot;http://search.cpan.org/dist/B-Debugger/&quot;&gt;B::Debugger&lt;/h3&gt;<br/>Debug B modules and optrees.<br/><br/>Thanks<br/>-- <br/>Reini Urban<br/>http://phpwiki.org/ http://murbreak.at/<br/> http://www.nntp.perl.org/group/perl.debugger/2010/01/msg131.html Mon, 18 Jan 2010 06:08:08 +0000 buggy debugger command 'a' in recent perls? by Heiko Eißfeldt Hello all,<br/><br/>I am having a little trouble with the action command &#39;a&#39;<br/>under recent perls.<br/><br/>For example when i use the following little program with the<br/>&#39;a&#39; (action) command in recent perls (up to 5.11.3) under linux,<br/>I am getting an unexpected warning message, after control leaves<br/>the scope of the subroutine. It looks to me as if the<br/>evaluation of the action is done at the wrong place<br/>(as $arg is not in scope anymore after &#39;return&#39;).<br/><br/>Can this be written into a test?<br/>Thanks, Heiko<br/><br/>simple.pl:<br/>==========================<br/>use strict; use warnings;<br/><br/>greet(&#39;Hello&#39;);<br/><br/>sub greet<br/>{<br/> my $arg = shift;<br/> print &quot;$arg\n&quot;;<br/> return;<br/>}<br/>==========================<br/><br/>A debugging session with an action that prints $arg, before the <br/>subroutine returns, follows. Please note the warning message at<br/>the end.<br/><br/>========================================================================<br/>heiko@heiko-desktop:~/perl/my_tests$ perl5.11.3 -wd simple.pl<br/><br/>Loading DB routines from perl5db.pl version 1.33<br/>Editor support available.<br/><br/>Enter h or `h h&#39; for help, or `man perldebug&#39; for more help.<br/><br/>sigwarn handler installed!<br/>main::(simple.pl:3): greet(&#39;Hello&#39;);<br/> DB&lt;1&gt; a 9 print &quot; \$arg = $arg\n&quot;<br/> DB&lt;2&gt; c 9<br/>Hello<br/>main::greet(simple.pl:9): return;<br/> $arg = Hello<br/> DB&lt;3&gt; s<br/>Debugged program terminated. Use q to quit or R to restart,<br/> use o inhibit_exit to avoid stopping after program termination,<br/> h q, h R or h o to get additional info.<br/>Use of uninitialized value $arg in concatenation (.) or string at (eval <br/>8)[/home/heiko/localperl/lib/5.11.3/perl5db.pl:638] line 1.<br/> $arg =<br/> DB&lt;3&gt;<br/>========================================================================<br/> http://www.nntp.perl.org/group/perl.debugger/2009/12/msg130.html Tue, 29 Dec 2009 04:56:51 +0000 Re: Strategies for using the debugger with complex applications by Andrew Brosnan Worked like a charm Peter. Thank you so much!<br/><br/><br/>On Dec 3, 2009, at 10:48 AM, Peter Scott wrote:<br/><br/>&gt; On Sat, 28 Nov 2009 16:05:35 -0500, Andrew Brosnan wrote:<br/>&gt;<br/>&gt;&gt; Hello,<br/>&gt;&gt;<br/>&gt;&gt; I&#39;m curious about the strategies that others use for running more<br/>&gt;&gt; complex applications in the debugger. A content management system for<br/>&gt;&gt; example might require session data and user input in order to run <br/>&gt;&gt; it&#39;s<br/>&gt;&gt; code, all of which gets processed along a journey through a large <br/>&gt;&gt; stack.<br/>&gt;&gt; How can I do &#39;something&#39; in a browser and then run that same <br/>&gt;&gt; request in<br/>&gt;&gt; the debugger?<br/>&gt;&gt;<br/>&gt;&gt; I see that Apache::DB does something similar where you can initiate a<br/>&gt;&gt; request in a browser and then control it in the debugger. But what if<br/>&gt;&gt; the app is not running mod_perl?<br/>&gt;<br/>&gt; If the program is a CGI then you can wrap it such that it runs ptkdb <br/>&gt; and<br/>&gt; remotes the debugger display to your screen via X. Then you invoke it<br/>&gt; form a browser and the debugger runs on the server invocation itself.<br/>&gt; Look up ptkdb documentation.<br/>&gt;<br/>&gt; -- <br/>&gt; Peter Scott<br/>&gt; http://www.perlmedic.com/<br/>&gt; http://www.perldebugged.com/<br/>&gt; http://www.informit.com/store/product.aspx?isbn=0137001274<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2009/12/msg129.html Thu, 03 Dec 2009 12:28:51 +0000 Re: Strategies for using the debugger with complex applications by Peter Scott On Sat, 28 Nov 2009 16:05:35 -0500, Andrew Brosnan wrote:<br/><br/>&gt; Hello,<br/>&gt; <br/>&gt; I&#39;m curious about the strategies that others use for running more<br/>&gt; complex applications in the debugger. A content management system for<br/>&gt; example might require session data and user input in order to run it&#39;s<br/>&gt; code, all of which gets processed along a journey through a large stack.<br/>&gt; How can I do &#39;something&#39; in a browser and then run that same request in<br/>&gt; the debugger?<br/>&gt; <br/>&gt; I see that Apache::DB does something similar where you can initiate a<br/>&gt; request in a browser and then control it in the debugger. But what if<br/>&gt; the app is not running mod_perl?<br/><br/>If the program is a CGI then you can wrap it such that it runs ptkdb and <br/>remotes the debugger display to your screen via X. Then you invoke it <br/>form a browser and the debugger runs on the server invocation itself. <br/>Look up ptkdb documentation.<br/><br/>-- <br/>Peter Scott<br/>http://www.perlmedic.com/<br/>http://www.perldebugged.com/<br/>http://www.informit.com/store/product.aspx?isbn=0137001274<br/> http://www.nntp.perl.org/group/perl.debugger/2009/12/msg128.html Thu, 03 Dec 2009 07:48:24 +0000 Re: Strategies for using the debugger with complex applications by Jan Ploski Hi Andrew,<br/><br/>One way to cope with the task you described is to use a debugger<br/>frontend such as EPIC. It allows you to set all the breakpoints<br/>in source files beforehand in the IDE, then it takes care of<br/>actually inserting those breakpoints at runtime whenever the right<br/>.pm files are loaded. It also includes an embedded web server through<br/>which the CGI scripts are executed (with the -d flag and PERLDB_OPTS<br/>set up to make them call back the IDE).<br/><br/>It is also possible to execute CGI scripts in the real web server<br/>and call back EPIC in a &quot;remote debugging&quot; configuration, but this<br/>would require some trickier configuration. Generally, I only use<br/>the debugger in a development environment, where the requirement<br/>of letting all requests go through a custom web server is not<br/>a big problem.<br/><br/>The usual scenario is to start this web server (or, as it is called<br/>in Eclipse, a &quot;debug launch configuration&quot;), then issue the required<br/>user interactions in the browser to reach the interesting state,<br/>finally enable some breakpoints in the source code and repeat the<br/>problematic request from the browser to make the debugger suspend.<br/><br/>Regards,<br/>Jan Ploski<br/><br/>On Sat, Nov 28, 2009 at 04:05:35PM -0500, Andrew Brosnan wrote:<br/>&gt; Hello,<br/>&gt; <br/>&gt; I&#39;m curious about the strategies that others use for running more <br/>&gt; complex applications in the debugger. A content management system for <br/>&gt; example might require session data and user input in order to run it&#39;s <br/>&gt; code, all of which gets processed along a journey through a large <br/>&gt; stack. How can I do &#39;something&#39; in a browser and then run that same <br/>&gt; request in the debugger?<br/>&gt; <br/>&gt; I see that Apache::DB does something similar where you can initiate a <br/>&gt; request in a browser and then control it in the debugger. But what if <br/>&gt; the app is not running mod_perl?<br/>&gt; <br/>&gt; Thanks<br/>&gt; Andrew<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2009/11/msg127.html Sat, 28 Nov 2009 16:42:40 +0000 Strategies for using the debugger with complex applications by Andrew Brosnan Hello,<br/><br/>I&#39;m curious about the strategies that others use for running more <br/>complex applications in the debugger. A content management system for <br/>example might require session data and user input in order to run it&#39;s <br/>code, all of which gets processed along a journey through a large <br/>stack. How can I do &#39;something&#39; in a browser and then run that same <br/>request in the debugger?<br/><br/>I see that Apache::DB does something similar where you can initiate a <br/>request in a browser and then control it in the debugger. But what if <br/>the app is not running mod_perl?<br/><br/>Thanks<br/>Andrew<br/> http://www.nntp.perl.org/group/perl.debugger/2009/11/msg126.html Sat, 28 Nov 2009 13:05:42 +0000 Re: Escape chars in the prompt of perl5db.pl by Peter Scott On Thu, 07 May 2009 07:43:59 +0800, Dasn wrote:<br/>&gt; I&#39;m writing a program to communicate with perl debugger. The thing I<br/>&gt; found hard to handle is the Escape chars output from the prompt, for<br/>&gt; example, on my platform, the &quot;DB&lt;1&gt;&quot; is:<br/>&gt; &quot;&lt;Esc&gt;[4m DB&lt;1&gt; &lt;Esc&gt;[24m&lt;Esc&gt;[1m&quot;<br/>&gt; <br/>&gt; My question is: Is it possible to turn off these escape chars in perldb,<br/>&gt; without changing perl5db.pl?<br/><br/>Try setting the TERM environment variable to &#39;dumb&#39;.<br/><br/>-- <br/>Peter Scott<br/>http://www.perlmedic.com/<br/>http://www.perldebugged.com/<br/>http://www.informit.com/store/product.aspx?isbn=0137001274<br/> http://www.nntp.perl.org/group/perl.debugger/2009/05/msg125.html Thu, 07 May 2009 06:45:18 +0000 Escape chars in the prompt of perl5db.pl by Dasn Hello, I hope this is the right place to ask this question.<br/><br/>I&#39;m writing a program to communicate with perl debugger. The thing I<br/>found hard to handle is the Escape chars output from the prompt, for<br/>example, on my platform, the &quot;DB&lt;1&gt;&quot; is: <br/> &quot;&lt;Esc&gt;[4m DB&lt;1&gt; &lt;Esc&gt;[24m&lt;Esc&gt;[1m&quot;<br/><br/>My question is: Is it possible to turn off these escape chars in perldb,<br/>without changing perl5db.pl?<br/><br/>Thanks, please Cc me.<br/><br/>-- <br/>Dasn<br/><br/> http://www.nntp.perl.org/group/perl.debugger/2009/05/msg124.html Thu, 07 May 2009 01:22:54 +0000