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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Nov 29 17:42:52 PST 2014


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

Brian Burg <burg at cs.washington.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burg at cs.washington.edu,
                   |                            |fpizlo at apple.com
            Summary|Web Inspector: [JSC]        |Web Inspector: a
                   |Ability to asynchronously   |newly-added breakpoint
                   |set breakpoints             |inside an infinite loop
                   |                            |never pauses the debugger
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Brian Burg <burg at cs.washington.edu> ---
(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.

-- 
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/20141130/458dc5a9/attachment-0002.html>


More information about the webkit-unassigned mailing list