Re: 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).

Comment on Re: Disabling a hardcoded breakpoint Select or Download Code

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]
Re^3: Disabling a hardcoded breakpoint by LanX (Saint) on Mar 11, 2016 at 16:24 UTC
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]
Re^3: Disabling a hardcoded breakpoint by hexcoder (Curate) on Mar 12, 2016 at 10:09 UTC
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]


more useful options
	PerlMonks

Re: Disabling a hardcoded breakpoint

update