[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

--- Comment #4 from Mark Lam <mark.lam at apple.com> ---
(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.

-- 
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/4bb2957d/attachment.html>