| Summary: | Crash under WebCore::DOMWindow::dispatchMessageEventWithOriginCheck attempting to log console message | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Joseph Pecoraro <joepeck> | ||||
| Component: | WebCore Misc. | Assignee: | Joseph Pecoraro <joepeck> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | ap, cdumez, commit-queue, joepeck, timothy | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Joseph Pecoraro
2015-06-17 19:00:09 PDT
I was able to reproduce this once, in the debugger, and verify that a caller of DOMWindow::console() was not handling the possible nullptr result.
PageConsoleClient* DOMWindow::console() const
{
if (!isCurrentlyDisplayedInFrame())
return nullptr;
return m_frame->page() ? &m_frame->page()->console() : nullptr;
}
I was unable to reproduce this reliably though. The test where I was able to get it was something like this, in the LayoutTests/http/tests/security/postMessage directory.
<script>
setTimeout(function() {
var frame = document.getElementById("iframe-localhost");
var frameWindow = frame.contentWindow;
var postMessageFunction = frameWindow.postMessage;
console.log("here0", frameWindow, postMessage)
postMessageFunction.call(frameWindow, "message", "http://www.example.com");
setTimeout(function() {
console.log("here1", frameWindow, postMessage)
postMessageFunction.call(frameWindow, "message", "http://www.example.com");
gc();
}, 1000);
setTimeout(function() {
frame.parentElement.removeChild(frame);
console.log("here2", frameWindow, postMessage)
postMessageFunction.call(frameWindow, "message", "http://www.example.com");
}, 2000);
setTimeout(function() {
console.log("here2", frameWindow, postMessage)
postMessageFunction.call(frameWindow, "message", "http://www.example.com");
}, 3000);
}, 0);
</script>
<iframe src="http://localhost:8000/security/postMessage/resources/post-message-listener.html" id="iframe-localhost" width="800" height="300" style="border: 1px solid black;"></iframe>
Being unable to reliably reproduce this, and since it is a very straight forward null check, I'm going to go ahead with a patch. If someone wants me to try more for a test, let me know and I'll spend more time looking into it.
Created attachment 255061 [details]
[PATCH] Proposed Fix
This feels like it should be testable. Perhaps Chris has an idea how? I would try going a garbage collection after the frame is removed, not before. Also, postMessage is likely red herring, I'd be trying a synchronous test along the lines of what Tim sent you in an e-mail. (In reply to comment #4) > This feels like it should be testable. Perhaps Chris has an idea how? > > I would try going a garbage collection after the frame is removed, not > before. Also, postMessage is likely red herring, I'd be trying a synchronous > test along the lines of what Tim sent you in an e-mail. Yep, this is almost identical to the test Tim sent me. postMessage is what gets us down the DOMWindow::dispatchMessageEventWithOriginCheck path, so I think it is required here? Though I had reproduced this once, in trying to re-reproduce it I threw in a number of gc() calls using <script src="/js-test-resources/js-test-pre.js"></script> and had no success =(. Oh, the fact that there was a gc() in what I had above was an accident. I had tested a gc after the frame was removed. Comment on attachment 255061 [details] [PATCH] Proposed Fix Clearing flags on attachment: 255061 Committed r185712: <http://trac.webkit.org/changeset/185712> All reviewed patches have been landed. Closing bug. |