Summary: | CoreIPC deadlocks when actively using LocalStorage | ||
---|---|---|---|
Product: | WebKit | Reporter: | Mariusz Nowak <medikoo+webkit.org> |
Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Major | CC: | andersca, ap, bburg, beidson |
Priority: | P2 | Keywords: | InRadar |
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
URL: | http://ldz-test4.medyk.org | ||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=149585 |
Description
Mariusz Nowak
2014-03-07 12:10:05 PST
You'll need to attach a smaller test case before anyone can investigate this further. Is this a synchronous or async XHR call? Does it hang when the inspector is closed, or only when open? I'd love to prepare smaller test case, but I'm not able. It looks it's related to how process is busy with other things. It doesn't depend on console being open. Although as console slows down process, error happens more likely when it's open. I explained how you can reproduce it in 100% reliable way, and you have access to specially added logs and readable code. Code related to problematic XMLHttpRequest call is just below few lines (21567 - 21606) of user.js file: var xhr = new XMLHttpRequest(), def = deferred(), interval; console.log("Initialize Xhr", url); xhr.open(method, url, true); xhr.onload = function () { var type; console.log("Xhr loaded!"); clearInterval(interval); if ((xhr.status < 200) && (xhr.status >= 300)) { def.reject(new Error(xhr.responseText)); return; } type = getType(xhr); if (type === 'application/json') { def.resolve(parse(xhr.response)); return; } def.resolve(xhr.response); }; xhr.onerror = function () { def.reject(new Error("Error occured")); }; xhr.onabort = function () { def.reject(new Error("Operation aborted")); }; xhr.upload.onabort = xhr.onabort; xhr.setRequestHeader("X-Requested-With", "XMLHttpRequest"); if (method === 'POST') { xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); xhr.send(stringify(data)); } else { xhr.send(); } interval = setInterval(function () { try { xhr.status; } catch (e) { console.error("Xhr status: Not accessible [" + e.message + "]"); return; } console.log("Xhr status: OK"); }, 100); As I mentioned, this XMLHttpRequest invalid state issue, happens only in WebKit/Safari, all other browsers (Firefox, Chrome, IE and also Opera) work 100% fine without a glitch. I can reproduce this. What happens here is that WebProcess sends a synchronous WebPageProxy::DecidePolicyForNavigationAction message to UI process, but never gets a response. UI process is completely idle, it simply drops the message on the floor! This is very very bad, and very surprising. Unfortunately, the site is unusable in debug builds - it runs some ultra heavy JavaScripts, so pages take minutes to load, and even then, the bug doesn't seem to occur. So this will be a challenge to investigate. Notably, we are not hitting any resource load limits, I didn't see NetworkProcess get more than 4-5 loads at a time. There is one code path where Connection fails to send a sync response, I can check if it's taken here. void Connection::dispatchMessage(std::unique_ptr<MessageDecoder> message) { // If there's no client, return. We do this after calling releaseArguments so that // the ArgumentDecoder message will be freed. if (!m_client) return; No, this is not it - DecidePolicyForNavigationAction doesn't reach Connection::dispatchMessage. Both WebProcess and UIProcess are actually stuck inside mach_msg() in Connection::sendOutgoingMessage(). WebProcess is trying to send a SetItem message, and UIProcess is trying to send a DidSetItem message (or potentially DispatchStorageEvent). When both processes are sending messages on the IPC.ReceiveQueue thread, they are not receiving messages, so there is no chance to get out of this deadlock. Perhaps we should add a timeout to mach_msg, and try receiving messages for a while if we can't send? Or use separate threads for sending and receiving? There's a new dispatch source that can be used to know when it's possible to send messages without blocking - I think we can use that. Are there any news on that one? It's still observable in Safari 9.1 This should be fixed with the fix for https://bugs.webkit.org/show_bug.cgi?id=165622 Possibly https://bugs.webkit.org/show_bug.cgi?id=149585 is a duplicate of this one *** This bug has been marked as a duplicate of bug 165622 *** |