[Webkit-unassigned] [Bug 41705] Web Inspector: a newly-added breakpoint inside an infinite loop never pauses the debugger

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=41705

Brian Burg <bburg at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bburg at apple.com

--- Comment #5 from Brian Burg <bburg at apple.com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170515/dd434853/attachment.html>