Bug 41705 – Web Inspector: a newly-added breakpoint inside an infinite loop never pauses the debugger

• Component: Web Inspector
• Status: NEW

[Alexei Masterov]

Created attachment 60638 [details]
file to help reproduce this bug

Users should be a able to set a breakpoint while the javascript code is running.

For example, in an attached page, once javascript enters infinite loop, if the user sets a breakpoint on line 7 for example, the debugger will not stop at this breakpoint.  Only after a user pauses script execution and resumes it, will the debugger stop at a breakpoint.

Desired behavior: debugger should stop at a breakpoint immediately after it is set, if the javascript execution passes a line on which a breakpoint was set.

[Brian Burg]

(Migrating to new component)

The TOT inspector no longer hangs forever when the inspected page hits an infinite loop (thanks multiprocess!), but you still can't pause at a breakpoint added after the iloop begins. For the breakpoint to take effect, the call stack has to be completely. I believe this is a pretty fundamental limitation of the current debugger design; all relevant code blocks need to be deoptimized on a subsequent event loop turn. (My shallow understanding is that this is because it's hard to make that safe to do with things on the stack. But why can JSC tier up or bail out with OSR but not exit to code with debugger opcodes?)

Mark or Fil, is there an easy way to support the use case of diagnosing an infinite loop? I don't care if it means a being able to hit a breakpoint, or just a way to automatically pause the debugger when user script gets stuck in an infinite loop after some sane timeout.

[Radar WebKit Bug Importer]

<rdar://problem/19281558>

[Blaze Burg]

*** Bug 40614 has been marked as a duplicate of this bug. ***

[Mark Lam]

(In reply to Brian Burg from comment #1)
> (Migrating to new component)
> 
> The TOT inspector no longer hangs forever when the inspected page hits an
> infinite loop (thanks multiprocess!), but you still can't pause at a
> breakpoint added after the iloop begins. For the breakpoint to take effect,
> the call stack has to be completely. I believe this is a pretty fundamental
> limitation of the current debugger design; all relevant code blocks need to
> be deoptimized on a subsequent event loop turn. (My shallow understanding is
> that this is because it's hard to make that safe to do with things on the
> stack. But why can JSC tier up or bail out with OSR but not exit to code
> with debugger opcodes?)
> 
> Mark or Fil, is there an easy way to support the use case of diagnosing an
> infinite loop? I don't care if it means a being able to hit a breakpoint, or
> just a way to automatically pause the debugger when user script gets stuck
> in an infinite loop after some sane timeout.

This is what the new VMTraps infrastructure is building towards.  Of course, a lot more needs to be done before we can get there.

[Blaze Burg]

(In reply to Mark Lam from comment #4)
> (In reply to Brian Burg from comment #1)
> > (Migrating to new component)
> > 
> > The TOT inspector no longer hangs forever when the inspected page hits an
> > infinite loop (thanks multiprocess!), but you still can't pause at a
> > breakpoint added after the iloop begins. For the breakpoint to take effect,
> > the call stack has to be completely. I believe this is a pretty fundamental
> > limitation of the current debugger design; all relevant code blocks need to
> > be deoptimized on a subsequent event loop turn. (My shallow understanding is
> > that this is because it's hard to make that safe to do with things on the
> > stack. But why can JSC tier up or bail out with OSR but not exit to code
> > with debugger opcodes?)
> > 
> > Mark or Fil, is there an easy way to support the use case of diagnosing an
> > infinite loop? I don't care if it means a being able to hit a breakpoint, or
> > just a way to automatically pause the debugger when user script gets stuck
> > in an infinite loop after some sane timeout.
> 
> This is what the new VMTraps infrastructure is building towards.  Of course,
> a lot more needs to be done before we can get there.

Cool, I just cleaned up a few bugs but didn't know if you had a bug or radar tracking the larger project.

[Blaze Burg]

*** Bug 158952 has been marked as a duplicate of this bug. ***