Bug 46770 – crash at lineBreakExistsAtPosition

• Status: RESOLVED
• Resolution: FIXED
• Component: HTML Editing

[Enrica Casucci]

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

[Enrica Casucci]

Created attachment 69141 [details]
Patch

[Darin Adler]

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.

[Enrica Casucci]

(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.

[Tony Chang]

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.

[Ryosuke Niwa]

(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.

[Enrica Casucci]

This is the only place I could find where we dereference the renderer without checking for null.

[Enrica Casucci]

Committed revision 68727.