in reply to Disabling a hardcoded breakpoint

You wrote:
The obvious and naive way is to comment out that bp and restart with frustration when the bp was discovered in a loop after a long processing.

If your are running the debugger interactively (with the -d option), you could continue the run with the c command instead of restarting.

If the script is run without the debugger, the line $DB::single = 1; has no effect (but causes a warning with -w), so I have some difficulty to recognize the merits of this method.

Obviously you could grep for $DB::single in your Perl sources to find any left-overs...

BTW: I am using an automatic breakpoint to catch the cause of any warnings during a run under the debugger. That is, whenever I get a warning about an undefined value being used in an addition for example, I let the debugger stop right there, so I can investigate the context that led to this behavior. The original source does not need to be modified (see here for details).

Replies are listed 'Best First'.
Re^2: Disabling a hardcoded breakpoint
by seki (Monk) on Mar 11, 2016 at 15:31 UTC
    If your are running the debugger interactively (with the -d option), you could continue the run with the c command instead of restarting.

    Yes, but my point is that I arrive on that BP in a loop, after a long processing. Sure I can continue, but if the loop is iterating 10_000 times, I won't type 10_000 times c+enter.
    That is why I asked if there could exist a useful incantation to skip the problematic BP.

    And many thanks for that trick of automatic breakpoints. I did not know that a warning at runtime was throwing a signal to the process that can be managed.
[reply]
      Look the breakpoint is set at runtime!

      ... you are free to code whatever you want to control it.

      Like using a sub dbbreak() 

      sub dbbreak {
   $DB::single = $DB::my_single_breaks_allowed;
}

      [download]

      would not only make your code more readable and it'll give you full flexibility for future changes.

      update

      if you make sure that setting $DB::single is the last command in the sub, then your break will happen after returning!

      just tested

      $DB::debugger_breaks_allowed =1;


sub break_db {
   $DB::single = $DB::debugger_breaks_allowed;
#   print "inside";
}


print "before";

break_db();
print "after"; #<-- breaks here

print "later";

      [download]

      And grepping your old code for $DB::single for replacement shouldn't be too problematic...

      Cheers Rolf
      (addicted to the Perl Programming Language and ☆☆☆☆ :)
      Je suis Charlie!

[reply]
[d/l]
[select]
      ok, maybe you can replace the hard coded breakpoints with
      • either a conditional breakpoint like this 

        if (some interesting abnormal condition) {
        $DB::single = 1;
}

        [download]
        (if you need them permanently in your code). This should trigger only when something is not as expected (so hopefully seldom).

      • or debug with the automatic breakpoint method, I mentioned in my first reply.
      • or use a conditional breakpoint from the debugger (b [line] [condition] from Debugger Commands)
[reply]
[d/l]

In Section Seekers of Perl Wisdom