This bug has been reported by several people. We don't have a repro case, but it seems related to typing in form controls. Here is the stacktrace: Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000004 Crashed Thread: 0 Thread 0 Crashed: 0 com.apple.WebCore 0x9282476d WebCore::lineBreakExistsAtPosition(WebCore::Position const&) + 125 1 com.apple.WebCore 0x928236c6 WebCore::InsertTextCommand::input(WebCore::String const&, bool) + 294 2 com.apple.WebCore 0x92822e8c WebCore::TypingCommand::insertTextRunWithoutNewlines(WebCore::String const&, bool) + 140 3 com.apple.WebCore 0x92822ddf WebCore::TypingCommand::insertText(WebCore::String const&, bool) + 351 4 com.apple.WebCore 0x928215c3 WebCore::TypingCommand::insertText(WebCore::Document*, WebCore::String const&, WebCore::VisibleSelection const&, bool, bool) + 659 5 com.apple.WebCore 0x92820c78 WebCore::Editor::insertTextWithoutSendingTextEvent(WebCore::String const&, bool, WebCore::Event*) + 1048 6 com.apple.WebCore 0x92820835 WebCore::EventHandler::defaultTextInputEventHandler(WebCore::TextEvent*) + 197 7 com.apple.WebCore 0x9263ddbb WebCore::Node::defaultEventHandler(WebCore::Event*) + 379 8 com.apple.WebCore 0x927026b8 WebCore::HTMLInputElement::defaultEventHandler(WebCore::Event*) + 600 9 com.apple.WebCore 0x9263d8f1 WebCore::Node::dispatchGenericEvent(WTF::PassRefPtr<WebCore::Event>) + 1297 10 com.apple.WebCore 0x9263d2a1 WebCore::Node::dispatchEvent(WTF::PassRefPtr<WebCore::Event>, int&) + 225 11 com.apple.WebCore 0x928205ce WebCore::EventHandler::handleTextInputEvent(WebCore::String const&, WebCore::Event*, bool, bool) + 238 12 com.apple.WebCore 0x928204d9 WebCore::Editor::insertText(WebCore::String const&, WebCore::Event*) + 57 13 com.apple.WebKit 0x932588bd -[WebHTMLView(WebNSTextInputSupport) insertText:] + 1229 14 com.apple.WebKit 0x9325830a -[WebHTMLView(WebInternal) _interceptEditingKeyEvent:shouldSaveCommand:] + 682 15 com.apple.WebKit 0x93258b4c WebEditorClient::handleKeyboardEvent(WebCore::KeyboardEvent*) + 108 16 com.apple.WebCore 0x9281fc99 WebCore::EventHandler::defaultKeyboardEventHandler(WebCore::KeyboardEvent*) + 217 17 com.apple.WebCore 0x9263dcaa WebCore::Node::defaultEventHandler(WebCore::Event*) + 106 18 com.apple.WebCore 0x927025f6 WebCore::HTMLInputElement::defaultEventHandler(WebCore::Event*) + 406 19 com.apple.WebCore 0x9263d8f1 WebCore::Node::dispatchGenericEvent(WTF::PassRefPtr<WebCore::Event>) + 1297 20 com.apple.WebCore 0x9263d2a1 WebCore::Node::dispatchEvent(WTF::PassRefPtr<WebCore::Event>, int&) + 225 21 com.apple.WebCore 0x9281f3f3 WebCore::EventHandler::keyEvent(WebCore::PlatformKeyboardEvent const&) + 1827 22 com.apple.WebCore 0x9281d068 WebCore::EventHandler::keyEvent(NSEvent*) + 296 23 com.apple.WebKit 0x93257ebd -[WebHTMLView keyDown:] + 269
Created attachment 69141 [details] Patch
Comment on attachment 69141 [details] Patch Normally we require a test for any bug fix. I am saying review+ on this even without a test, but it seems that given you understanding of the cause you could construct a test.
(In reply to comment #2) > (From update of attachment 69141 [details]) > Normally we require a test for any bug fix. I am saying review+ on this even without a test, but it seems that given you understanding of the cause you could construct a test. I still want to spend some more time trying to create a test. What makes me feel comfortable landing this patch without a test, is the fact that this is the only case of dereferencing of a render object that is performed without checking for null that I could find in Webcore.
If it helps, many of the crash dumps in Chromium have http://www.netflix.com/WiHome as the crashing URL. The chromium crash report is here: http://code.google.com/p/chromium/issues/detail?id=29253 Ryosuke also suspects that this null check is all that we need to do, but a repro would still be nice.
(In reply to comment #4) > If it helps, many of the crash dumps in Chromium have http://www.netflix.com/WiHome as the crashing URL. > > The chromium crash report is here: http://code.google.com/p/chromium/issues/detail?id=29253 > > Ryosuke also suspects that this null check is all that we need to do, but a repro would still be nice. Oh yeah, I spent sometime investigating that bug and it's to do with input element. I remembre it was hard to reproduce. But every time I could reproduce, it was right after the page load. I had to move back & forth between pages to reproduce it.
This is the only place I could find where we dereference the renderer without checking for null.
Committed revision 68727.