Codacoder Reporter
	Description • 11 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140212131424

Steps to reproduce:

1 - Write some code and bring it up in the debugger
2 - Set a breakpoint somewhere to gain access to debugger
3 - Set a breakpoint in a function "A"
4 - Add a watch expression that will now call A()


Actual results:

infinite loop:
  A
  eval
  eval
  A
  eval
  eval
  A
  eval
  eval



Expected results:

debugger should handle this better

	:Gijs (he/him)
	Comment 1 • 11 years ago

(In reply to Russ from comment #0)
> debugger should handle this better

Can you define this more precisely? What does 'better' mean in this case?

	Codacoder Reporter
	Comment 2 • 11 years ago

The problem appears to be that the watch+bp is being re-evaluated over and over. Once the watched expression's bp is hit and then resumed/exited/returned, it should not go back in (unless it's edited, of course).

Similar to how a watch expression of the form x = y is implemented?

So better means, improve how the debugger handles this scenario because what it's doping right now is broken.

	:Gijs (he/him)
	Comment 3 • 11 years ago

(In reply to Russ from comment #2)
> The problem appears to be that the watch+bp is being re-evaluated over and
> over. Once the watched expression's bp is hit and then
> resumed/exited/returned, it should not go back in (unless it's edited, of
> course).

This doesn't make sense. A watch expression's result can change:

let a = 5;
a = 7;
a = 9;

if I'm setting a watch expression for 'a', and I step through this code, shouldn't the expression update?


I think what you actually want is for the execution of a watch's code to set a flag to ignore breakpoints.

	Codacoder Reporter
	Comment 4 • 11 years ago

Actually, discussing a hypothetical rabbit-trail which maybe a badly expressed example doesn't make sense.  Your example is a trivial example: of course that's wanted behavior so let's not waste time discussing it.

The bug is the never ending re-evaluation of the watched expression and the debugger "losing its place".  The call stack grows and grows which is not what the codebase is doing - it's what the debugger is doing. THAT is the bug.  But just to go back to your example: if you COULD set a breakpoint inside a=5, you would have a=5 called over and over... got it?

Hopefully, this next will help clarify: "never ending re-evaluation" means (apart from the obvious) you never see the original code again.  It's gone. Period.  It's as though when the debugger hit the watch's bp, all record of the former stack has been erased and it has no way back.  When it tries, it see the watch expression again (a call to A() in my example) and jumps there. Again. And Again. And Again.

Another symptom: "Oh, I'll just close the debugger and reopen it."  Nope.  Sources has maybe 10 files in it where it should have 50+ (it seems to be unable to list scripts from iframes though I have not proved that).

So no, I don't want to ignore bps inside watches; I WANT to be able to call my code from a watch and if I set a bp inside the watched expression I WANT the debugger to continue working correctly.  i.e. "better".

	Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]
	Comment 5 • 11 years ago

(In reply to :Gijs Kruitbosch from comment #3)
> I think what you actually want is for the execution of a watch's code to set
> a flag to ignore breakpoints.

Yeah we need this. Not just for breakpoints but debugger statements and pause-on-exception and all that, too.