[Webkit-unassigned] [Bug 52945] crash @ WebCore::ResourceLoader::didCancel(WebCore::ResourceError const &)

[bugzilla-daemon at webkit.org]

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





--- Comment #2 from raman tenneti <rtenneti at chromium.org>  2011-01-21 19:56:01 PST ---
>From    Jim Roskind <jar at google.com>
date    Fri, Jan 21, 2011 at 1:50 PM

Interesting.... so if it is all single threaded, and scheduling is the issue... then the thread must (deep down) start to service messages again (effectively yielding to other pending tasks).  Is this part of the webkit model?  Are tasks allowed to suspend in such a way?

Having argued strongly on Chrome *against* nested message loops (places where threads can pause/yield), I'm sad to hear that Webkit would expose such a "feature."

Where would a breakpoint need to be placed in webkit to catch such a re-entrant dispatcher?  Putting a breakpoint there would prove your point (that re-entrancy was facilitated).  It would also make it clear where the null check has to be to ensure that it is after any/all plausible re-entrancy has completed.

Jim

- Show quoted text -

>From    Adam Barth <abarth at google.com>
date    Fri, Jan 21, 2011 at 2:52 PM

WebKit does run nested message loops because of things like
synchronous XMLHttpRequest.  You'd see them on the stack though.  Much
of WebKit needs to be re-entrant because we call out to JavaScript,
which can call back into WebCore.

Adam

    chrome.dll!WebKit::WebView::didExitModalLoop()  Line 257 + 0x25
bytes    C++

That frame is indicative of a nested message loop.  We had a modal
loop with a bunch of junk on the stack.

Adam

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.