Starting with WebKit-SVN-r18333.dmg, JsUnit's testRunner.html (v 2.1) page causes WebKit to crash. 1. Download JsUnit: http://downloads.sourceforge.net/jsunit/jsunit2_1.zip?modtime=1091836800&big_mirror=0 2. Open testRunner.html 3. Observe crash
Created attachment 12174 [details] zipped crash log
I can't reproduce this with the r18333 nightly or my locally built copy of r18517 - perhaps this is an Intel-only bug? (I'm on a G4)
Thanks for the bug report, Jesse! A couple of items: 1. Could you attach the testRunner.html file to this bug (if it's not too big and there's no license restriction against doing that)? That would speed up the bug resolution process. 2. When attaching a crash log, please note that you only need to include the "last" crash log in Safari.crash.log. Crash logs are separated by "**********", so just make a copy of the file and delete everything above the last "**********" line.
(In reply to comment #2) > I can't reproduce this with the r18333 nightly or my locally built copy of > r18517 - perhaps this is an Intel-only bug? (I'm on a G4) The last stack trace indicates a division-by-zero error, which (as I recall) is "more fatal" on x86 than it is on PPC, so that jibes with your findings Matt! Here's the top of the stack trace: Exception: EXC_ARITHMETIC (0x0003) Codes: EXC_I386_DIV (divide by zero) Thread 0 Crashed: 0 com.apple.WebCore 0x01263488 WebCore::RenderFrameSet::layOutAxis(WebCore::RenderFrameSet::GridAxis&, WebCore::Length const*, int) + 1028 1 com.apple.WebCore 0x0126385a WebCore::RenderFrameSet::layout() + 156 2 com.apple.WebCore 0x0114973f WebCore::RenderBlock::layoutBlockChildren(bool) + 701 3 com.apple.WebCore 0x01149f25 WebCore::RenderBlock::layoutBlock(bool) + 1141 4 com.apple.WebCore 0x0113f912 WebCore::RenderBlock::layout() + 28 5 com.apple.WebCore 0x0114973f WebCore::RenderBlock::layoutBlockChildren(bool) + 701 6 com.apple.WebCore 0x01149f25 WebCore::RenderBlock::layoutBlock(bool) + 1141 7 com.apple.WebCore 0x0113f912 WebCore::RenderBlock::layout() + 28 8 com.apple.WebCore 0x01153ac8 WebCore::RenderView::layout() + 60 9 com.apple.WebCore 0x010d6915 WebCore::FrameView::layout(bool) + 327 10 com.apple.WebCore 0x012627c9 WebCore::RenderPart::updateWidgetPosition() + 533 11 com.apple.WebCore 0x0115429a WebCore::RenderView::updateWidgetPositions() + 94 12 com.apple.WebCore 0x010d6d4d WebCore::FrameView::layout(bool) + 1407 13 com.apple.WebCore 0x010d8645 WebCore::Document::updateLayout() + 81 14 com.apple.WebCore 0x010cf4fe WebCore::Frame::setIsActive(bool) + 558 15 com.apple.WebKit 0x00332f94 -[WebHTMLView resignFirstResponder] + 156 16 com.apple.AppKit 0x932b9406 -[NSWindow makeFirstResponder:] + 107 17 com.apple.Safari 0x00013d4d 0x1000 + 77133 18 com.apple.Safari 0x0002e346 0x1000 + 185158 19 libobjc.A.dylib 0x90a57c56 objc_msgSendv + 54 [...]
Confirmed. This crashes on Intel 10.4.8 (8N1037), but not on PowerPC 10.4.8 (8L127).
Created attachment 12177 [details] jsunit-testRunner.webarchive (crashes Intel) Test case saved as webarchive on PowerPC Mac. Will crash Intel Mac.
Created attachment 12196 [details] Reduction (will crash) RenderFrameSet::layOutAxis() gets called with negative availableLength since the very little width that there is gets eaten up by borders.
Created attachment 12199 [details] Patch Before r18333, RenderFrameSet had logic to change a negative available width to zero before laying out the grid. The end result in that case was just a vector of zeros.
Comment on attachment 12199 [details] Patch Mitz is going to submit a new patch.
Created attachment 12201 [details] Treat negative availableLength as zero This just restores the old behavior.
Comment on attachment 12201 [details] Treat negative availableLength as zero r=me (my bad, thanks for the fix)
Committed revision 18571.