WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
3560
page with use of first-letter crashes reproducibly in RenderObject::renderArena()
https://bugs.webkit.org/show_bug.cgi?id=3560
Summary
page with use of first-letter crashes reproducibly in RenderObject::renderAre...
Jens Ayton
Reported
2005-06-15 23:12:34 PDT
When page is opened, it initially displays correctly. The application is unresponsive. After a couple of seconds, it crashes. This is known to occur in Safari 1.2, 1.3 and 2.0, and in Xyle scope 1.0.1, and has been observed on a number of machines, and is consistent. This has been reported before via Safari's bug report button, but there doesn't appear to be a corresponding report in Bugzilla. The maintainer of the page recently bought a Powerbook. I'll try to poke him into adjusting it and trying to isolate the crash. Backtrace and stuff: Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x7c4002aa Thread 0 Crashed: 0 com.apple.WebCore 0x962f81e4 khtml::RenderObject::renderArena() const + 0x18 1 com.apple.WebCore 0x9645bb64 khtml::appendRunsForObject(int, int, khtml:: RenderObject*, khtml::BidiState&) + 0x210 2 com.apple.WebCore 0x9645bc38 khtml::appendRun(khtml::BidiState&) + 0x80 3 com.apple.WebCore 0x9645cdc4 khtml::RenderBlock::bidiReorderLine(khtml::BidiIterator const&, khtml::BidiIterator const&, khtml::BidiState&) + 0x9a8 4 com.apple.WebCore 0x962f13c4 khtml::RenderBlock::layoutInlineChildren(bool) + 0x7f0 5 com.apple.WebCore 0x962f56f8 khtml::RenderBlock::layoutBlock(bool) + 0x2b4 6 com.apple.WebCore 0x962ee918 khtml::RenderBlock::layoutBlockChildren(bool) + 0x2b8 7 com.apple.WebCore 0x962f5710 khtml::RenderBlock::layoutBlock(bool) + 0x2cc 8 com.apple.WebCore 0x962ee918 khtml::RenderBlock::layoutBlockChildren(bool) + 0x2b8 9 com.apple.WebCore 0x962f5710 khtml::RenderBlock::layoutBlock(bool) + 0x2cc 10 com.apple.WebCore 0x962ee918 khtml::RenderBlock::layoutBlockChildren(bool) + 0x2b8 11 com.apple.WebCore 0x962f5710 khtml::RenderBlock::layoutBlock(bool) + 0x2cc 12 com.apple.WebCore 0x962ee918 khtml::RenderBlock::layoutBlockChildren(bool) + 0x2b8 13 com.apple.WebCore 0x962f5710 khtml::RenderBlock::layoutBlock(bool) + 0x2cc 14 com.apple.WebCore 0x962ee918 khtml::RenderBlock::layoutBlockChildren(bool) + 0x2b8 15 com.apple.WebCore 0x962f5710 khtml::RenderBlock::layoutBlock(bool) + 0x2cc 16 com.apple.WebCore 0x9631291c khtml::RenderCanvas::layout() + 0xfc 17 com.apple.WebCore 0x9631a234 KHTMLView::layout() + 0x318 18 com.apple.WebCore 0x9647bd30 DOM::DocumentImpl::implicitClose() + 0x310 19 com.apple.WebCore 0x9632fff8 KHTMLPart::checkEmitLoadEvent() + 0x22c 20 com.apple.WebCore 0x963171d4 KHTMLPart::checkCompleted() + 0xe4 21 com.apple.WebCore 0x96303084 KWQSignal::call(khtml::DocLoader*, khtml::CachedObject*) const + 0x90 22 com.apple.WebCore 0x9645a45c khtml::Loader::slotFinished(KIO::Job*, NSData*) + 0x1ac 23 com.apple.WebCore 0x964950d8 KWQSignal::call(KIO::Job*, NSData*) const + 0x90 24 com.apple.WebCore 0x9649aa1c -[KWQResourceLoader finishJobAndHandle:] + 0x3c 25 com.apple.WebKit 0x9605cb78 -[WebSubresourceClient didFinishLoading] + 0x48 26 com.apple.Foundation 0x90a6dea4 -[NSURLConnection(NSURLConnectionInternal) _sendDidFinishLoadingCallback] + 0x4c 27 com.apple.Foundation 0x90a3d354 -[NSURLConnection(NSURLConnectionInternal) _sendCallbacks] + 0x1f8 28 com.apple.Foundation 0x90a279e4 -[NSArray makeObjectsPerformSelector:withObject:] + 0x108 29 com.apple.Foundation 0x90a51b7c _sendCallbacks + 0xd4 30 com.apple.CoreFoundation 0x901c3c88 __CFRunLoopDoSources0 + 0x1fc 31 com.apple.CoreFoundation 0x901c1540 __CFRunLoopRun + 0x1b0 32 com.apple.CoreFoundation 0x901c5e6c CFRunLoopRunSpecific + 0x148 33 com.apple.HIToolbox 0x92885f60 RunCurrentEventLoopInMode + 0xac 34 com.apple.HIToolbox 0x9288c6c8 ReceiveNextEventCommon + 0x17c 35 com.apple.HIToolbox 0x928ae6a0 BlockUntilNextEventMatchingListInMode + 0x60 36 com.apple.AppKit 0x92e826dc _DPSNextEvent + 0x180 37 com.apple.AppKit 0x92e9915c -[NSApplication nextEventMatchingMask:untilDate:inMode: dequeue:] + 0x74 38 com.apple.Safari 0x0000bd24 0x1000 + 0xad24 39 com.apple.AppKit 0x92ead4dc -[NSApplication run] + 0x21c 40 com.apple.AppKit 0x92f69bec NSApplicationMain + 0x1d0 41 com.apple.Safari 0x00007fc4 0x1000 + 0x6fc4 42 com.apple.Safari 0x000546e8 0x1000 + 0x536e8
Attachments
Reduced test case from hol.istic.net
(1.37 KB, text/html)
2005-06-16 17:25 PDT
,
Chris Petersen
no flags
Details
no test case yet, but would like a first pass of review anyway
(63.30 KB, patch)
2006-03-06 00:36 PST
,
Darin Adler
no flags
Details
Formatted Diff
Diff
Proposed fix, no test and change log yet
(4.31 KB, patch)
2006-03-11 15:39 PST
,
mitz
no flags
Details
Formatted Diff
Diff
Same patch, with layout test and change log
(10.04 KB, patch)
2006-03-12 07:24 PST
,
mitz
mjs
: review+
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Jens Ayton
Comment 1
2005-06-15 23:14:29 PDT
Clarification: the page in question is that specified in the "URL" field of the report, i.e. http:// hol.istic.net/
Nicholas 'Aquarion' Avenell
Comment 2
2005-06-16 01:37:39 PDT
The page with the example on it is mine. I'm going to leave that precise page alone until I can reproduce the exact bug on a static page (Downloading to desktop apparently stops the thing from crashing) for the purposes of debugging. If move the broken page (Pretty likely, as Jens mentioned I'm now on a powerbook, and my site crashing it is annoying ;-) I'll note here where it's gone.
Chris Petersen
Comment 3
2005-06-16 15:51:12 PDT
I'm getting a crash when I load the page in both TOT Webkit and Safari 2.0 (v412).
Chris Petersen
Comment 4
2005-06-16 15:56:24 PDT
Setting to P1 since this is a crash
Chris Petersen
Comment 5
2005-06-16 17:23:49 PDT
Attaching test case of problem.
Chris Petersen
Comment 6
2005-06-16 17:25:40 PDT
Created
attachment 2411
[details]
Reduced test case from hol.istic.net Opening this test case in Safari 2.0 or TOT Webkit results in a crash
Chris Petersen
Comment 7
2005-06-16 17:39:46 PDT
The test case uses a script that affects several H3 elements in the BODY. The crash occurs when the first-letter pseudo selector is applied to one of these heading : <h3 id="versionsTitle">versionsTitle</h3>. When the script attempts to manipulating this element , a crash occurs. function versionsInit(){ thing = document.getElementById("revisionsList"); content = thing.innerHTML; if (content == ""){ document.getElementById("revisions").style.display = "none"; } else { header = document.getElementById("versionsTitle"); header.onclick = toggleVersions; header.content = header.innerHTML thing.style.display = "none"; header.innerHTML = "+ "+header.content; } } If you remove this first-letter pseudo selector, the crash no longer occurs.
Alice Liu
Comment 8
2005-11-04 11:28:06 PST
unable to reproduce
Nicholas 'Aquarion' Avenell
Comment 9
2005-11-04 12:04:49 PST
Okay, From here (Safari 2.0.2 (416.12)) Clicking on the reduced test case crashes it out still (It no longer applies to Hol.istic.net itself since I Saw The Light, bought a Powerbook and started to care a lot more about being able to visit my own website in Safari)
Darin Adler
Comment 10
2005-12-11 20:15:55 PST
After a little debugging, the problem is obvious, but the solution is not yet obvious. The RenderTextFragment created for the first letter points to the same text node as the RenderTextFragment for the remaining text. But the text node only points to the remaining text renderer. Thus the text node's detach method only destroys the remaining text RenderTextFragment, orphaning a RenderTextFragment that now points to a non-existent node. We have to change something so that both renderers get destroyed. Maybe this can be special code in RenderTextFragment that knows about the other RenderTextFragment so that destroying one will destroy both.
Alice Liu
Comment 11
2006-01-09 17:40:38 PST
<
rdar://problem/4330356
>
Alice Liu
Comment 12
2006-01-09 17:41:44 PST
***
Bug 4269
has been marked as a duplicate of this bug. ***
Darin Adler
Comment 13
2006-03-06 00:36:37 PST
Created
attachment 6892
[details]
no test case yet, but would like a first pass of review anyway
mitz
Comment 14
2006-03-06 00:43:17 PST
(In reply to
comment #13
)
> Created an attachment (id=6892) [edit]
Wrong patch or wrong bug?
Darin Adler
Comment 15
2006-03-06 09:00:03 PST
Comment on
attachment 6892
[details]
no test case yet, but would like a first pass of review anyway Oops. Attached this patch to the wrong bug!
mitz
Comment 16
2006-03-11 15:39:07 PST
Created
attachment 7012
[details]
Proposed fix, no test and change log yet I didn't bother with anything more generic than the first-letter case as it seems to be unique. Do you think firstLetter() belongs in a subclass (RenderTextFragmentRemaining?)? Please r- since there's no test and change log.
Darin Adler
Comment 17
2006-03-11 22:13:23 PST
Comment on
attachment 7012
[details]
Proposed fix, no test and change log yet Looks like a good fix to me.
mitz
Comment 18
2006-03-12 07:24:54 PST
Created
attachment 7024
[details]
Same patch, with layout test and change log
Beth Dakin
Comment 19
2006-03-17 09:45:51 PST
I committed this patch.
mitz
Comment 20
2006-03-17 14:18:15 PST
http://build.webkit.org/results/post-commit-leaks-powerpc-mac-os-x/598/DumpRenderTree-leaks.txt
This patched causes RenderTextFragments to leak. Investigating...
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug