Closed
Bug 378027
Opened 18 years ago
Closed 17 years ago
Printing crash [@ nsCellMap::GetCellInfoAt] Exception: EXC_BAD_INSTRUCTION (0x0002)
Categories
(Core :: Layout: Tables, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: devon, Assigned: MatsPalmgren_bugz)
References
()
Details
(4 keywords, Whiteboard: [sg:moderate?][needs patch] using freed frame)
Crash Data
Attachments
(5 files)
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 Firefox crashes every time with an EXC_BAD_INSTRUCTION exception when trying to print a particular page from Intuit.com; a product order page. The original page is from intuit.com. A web complete source page and supporting images,etc are attached to this bug. The crash is 100% reproducible with this page content on MacOS X 10.4.9 with Firefox 2.0.0.3 (20070309). Reproducible: Always Steps to Reproduce: 1. Using Firefox 2.0.0.3 (20070309)... 2. Open the attached 'edit_confirmation.html' file. 3. Once open, click on the 'Print this page' icon/link on the page. 4. When the OS print dialog comes up, select 'Print' Actual Results: Firefox crashes after you have clicked 'Print' and the print dialog has been dismissed. Exception: EXC_BAD_INSTRUCTION (0x0002) Expected Results: Firefox should successfully print the page. This sample page content prints fine on Windows Vista with Firefox 2.0.0.3 (20070309). Attached is a sample 'order_confirmation.xps' of the page output from Windows Vista.
Reporter | ||
Comment 1•18 years ago
|
||
The attached *.zip file contains crashlogs, and a web complete *.html page and files that crash Firefox everytime when a print is attempted.
Reporter | ||
Comment 2•18 years ago
|
||
Win Vista xps output of sample page (what print output should look like)
Reporter | ||
Comment 3•18 years ago
|
||
Safari printed PDF output of sample page. This is a PDF that Firefox should be able to produce, through the OS, just like Safari does.
Reporter | ||
Comment 4•18 years ago
|
||
Comment on attachment 262126 [details]
crashlogs and web complete page sample that causes crash
updated comment on crashlogs and sample page attachment.
Attachment #262126 -
Attachment description: web complete page sample that causes print crash → crashlogs and web complete page sample that causes crash
Comment 5•18 years ago
|
||
Do you have also a Talkback ID from this crashs ? (http://kb.mozillazine.org/Talkback)
Reporter | ||
Comment 6•18 years ago
|
||
Talkback (v2.0.0.3) add-on is installed and enabled. Talkback never activates and/or catches the crash though.
Reporter | ||
Comment 7•18 years ago
|
||
Because the crash is occuring in nsTableCellMap (under nsTableFrame), I started eliminating table data in the *.html file one by one to identify the offending table. The offending table is the 'Shipping Address" <div> block. - if you remove the contents of the <div> block the page will print fine. - if you remove both "class" and "style" on the <div> block the page will print fine. - if you remove just the "class" on the <div> block the page will crash printing. - if you remove just the "style" on the <div> block the page will crash printing. It doesn't look like the css used on this <div> block is the problem though. If you use the previous <div> block's css, the "wcgBillingAddress", the page will still crash printing. Together, both "class" and "style" props are leading to the crash but there is nothing invalid with their syntax.
Reporter | ||
Comment 8•18 years ago
|
||
minor typo correction: "The offending table data is..."
Reporter | ||
Comment 9•18 years ago
|
||
actually, it's a combination of both <div> elements for "Billing Address" and "Shipping Address". If you comment out either one of them, the other will print just fine. When you remove both "class" and "style" props on both <div> elements, the page prints fine. Maybe the combination of usage for the table <div> elements here will ring a bell with someone who understands the rendering engine in Firefox a lot better than I do. :-)
Comment 10•18 years ago
|
||
if you can reduce the crash to a smaller file, please attach that crashing reduced testcase, thanks.
Component: OS Integration → Layout
Product: Firefox → Core
QA Contact: os.integration → layout
Assignee | ||
Updated•18 years ago
|
Group: security
Status: UNCONFIRMED → NEW
Component: Layout → Layout: Tables
Ever confirmed: true
QA Contact: layout → layout.tables
Whiteboard: [sg:critical?] using freed frame
Version: unspecified → 1.8 Branch
Assignee | ||
Comment 11•18 years ago
|
||
There are two of these before the crash: "Deleting out of flow without tearing down placeholder relationship" I don't know if they are related to the crash but I included a backtrace for them anyway.
Assignee | ||
Comment 12•18 years ago
|
||
The top of the crash stack is: #0 0x025d3164 in ?? () #1 0x187e4d6b in nsCellMap::GetCellInfoAt (this=0x37605560, aMap=@0x3737d870, aRowX=1, aColX=1, aOriginates=0xbfff5330, aColSpan=0xbfff532c) at nsCellMap.cpp:2554 #2 0x187e4e3c in nsTableCellMap::GetCellInfoAt (this=0x3737d870, aRowIndex=1, aColIndex=1, aOriginates=0xbfff5330, aColSpan=0xbfff532c) at nsCellMap.cpp:882 #3 0x187f0d7a in nsTableFrame::GetCellInfoAt (this=0x25b8370, aRowX=1, aColX=1, aOriginates=0xbfff5330, aColSpan=0xbfff532c) at nsTableFrame.cpp:4578 #4 0x187de279 in BasicTableLayoutStrategy::AssignPctColumnWidths (this=0x366d9b20, aReflowState=@0xbfff581c, aAvailWidth=7360, aTableIsAutoWidth=0, aPixelToTwips=15) at BasicTableLayoutStrategy.cpp:1414 #5 0x187dfc38 in BasicTableLayoutStrategy::BalanceColumnWidths (this=0x366d9b20, aReflowState=@0xbfff581c) at BasicTableLayoutStrategy.cpp:244 #6 0x187f5f92 in nsTableFrame::BalanceColumnWidths (this=0x25b8370, aReflowState=@0xbfff581c) at nsTableFrame.cpp:3462 #7 0x18801ff1 in nsTableFrame::ReflowTable (this=0x25b8370, aDesiredSize=@0xbfff5ab4, aReflowState=@0xbfff581c, aAvailHeight=7755, aReason=eReflowReason_Resize, aLastChildReflowed=@0xbfff56ec, aDidBalance=@0xbfff5724, aStatus=@0xbfff650c) at nsTableFrame.cpp:2165 #8 0x18802e21 in nsTableFrame::Reflow (this=0x25b8370, aPresContext=0x3760ff60, aDesiredSize=@0xbfff5ab4, aReflowState=@0xbfff581c, aStatus=@0xbfff650c) at nsTableFrame.cpp:2014 #9 0x186af316 in nsContainerFrame::ReflowChild (this=0x25b821c, aKidFrame=0x25b8370, aPresContext=0x3760ff60, aDesiredSize=@0xbfff5ab4, aReflowState=@0xbfff581c, aX=0, aY=75, aFlags=3, aStatus=@0xbfff650c) at nsContainerFrame.cpp:905 #10 0x18807e7a in nsTableOuterFrame::OuterReflowChild (this=0x25b821c, aPresContext=0x3760ff60, aChildFrame=0x25b8370, aOuterRS=@0xbfff5d40, aMetrics=@0xbfff5ab4, aAvailWidth=7350, aDesiredSize=@0xbfff5be8, aMargin=@0xbfff5bd8, aMarginNoAuto=@0xbfff5bc8, aPadding=@0xbfff5bb8, aReflowReason=eReflowReason_Resize, aStatus=@0xbfff650c, aNeedToReflowCaption=0x0) at nsTableOuterFrame.cpp:1316 #11 0x1880a361 in nsTableOuterFrame::Reflow (this=0x25b821c, aPresContext=0x3760ff60, aDesiredSize=@0xbfff5efc, aOuterRS=@0xbfff5d40, aStatus=@0xbfff650c) at nsTableOuterFrame.cpp:1961 #12 0x186a5857 in nsBlockReflowContext::ReflowBlock (this=0xbfff5eb8, aSpace=@0xbfff5f78, aApplyTopMargin=1, aPrevMargin=@0xbfff5f60, aClearance=0, aIsAdjacentWithTop=0, aComputedOffsets=@0x37604218, aFrameRS=@0xbfff5d40, aFrameReflowStatus=@0xbfff650c) at nsBlockReflowContext.cpp:605 #13 0x18699c0f in nsBlockFrame::ReflowFloat (this=0x25b26fc, aState=@0xbfff6bc8, aPlaceholder=0x25b840c, aFloatCache=0x37604200, aReflowStatus=@0xbfff650c) at nsBlockFrame.cpp:6085 #14 0x186a7f89 in nsBlockReflowState::FlowAndPlaceFloat (this=0xbfff6bc8, aFloatCache=0x37604200, aIsLeftFloat=0xbfff6248, aReflowStatus=@0xbfff650c, aForceFit=0) at nsBlockReflowState.cpp:850 #15 0x186a8c29 in nsBlockReflowState::AddFloat (this=0xbfff6bc8, aLineLayout=@0xbfff6628, aPlaceholder=0x25b840c, aInitialReflow=0, aReflowStatus=@0xbfff650c) at nsBlockReflowState.cpp:634 #16 0x18b3bd19 in nsLineLayout::AddFloat (this=0xbfff6628, aFrame=0x25b840c, aReflowStatus=@0xbfff650c) at nsLineLayout.h:260 #17 0x186f084e in nsLineLayout::ReflowFrame (this=0xbfff6628, aFrame=0x25b840c, aReflowStatus=@0xbfff650c, aMetrics=0x0, aPushedFrame=@0xbfff6508) at nsLineLayout.cpp:1017
Assignee | ||
Updated•18 years ago
|
Summary: Printing crash in nsTableCellMap(); Exception: EXC_BAD_INSTRUCTION (0x0002) → Printing crash [@ nsCellMap::GetCellInfoAt] Exception: EXC_BAD_INSTRUCTION (0x0002)
Assignee | ||
Comment 13•18 years ago
|
||
The bug depends on the page size, I can only reproduce the crash on Mac after changing the default page size (A4) to US/Letter. I can also crash a SeaMonkey 1.8 branch debug build on Linux, but only with US/Letter and in Landscape mode.
Assignee | ||
Comment 14•18 years ago
|
||
Comment 15•18 years ago
|
||
Reducing impact to sg:moderate on the grounds that an average web surfer isn't going to click print on a random malicious page. (The page could call window.print(), but the user is likely to cancel a page that's trying to suspiciously print itself. Even if it's pr0n -- who wants the evidence lying around for the girlfriend to find?)
Whiteboard: [sg:critical?] using freed frame → [sg:moderate?] using freed frame
![]() |
||
Updated•18 years ago
|
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
Comment 16•18 years ago
|
||
Mats does this crash trunk?
Assignee | ||
Comment 17•18 years ago
|
||
(In reply to comment #16) > Mats does this crash trunk? No, it's branch only AFAICT (tested Linux and MacOSX).
Assignee | ||
Comment 18•18 years ago
|
||
This regressed *on the 1.8 branch* in this range: 2005-09-30-05 -- 2005-10-01-05 That is between Firefox 1.5 beta 1 and beta 2. http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-09-30+04%3A00&maxdate=2005-10-01+06%3A00&cvsroot=%2Fcvsroot
Keywords: regression
Comment 19•18 years ago
|
||
my guess would then be bug 295815
Assignee | ||
Comment 20•18 years ago
|
||
Backing out bug 295815 did not help. Same crash.
Assignee | ||
Comment 21•18 years ago
|
||
Just to be clear, what I meant above was: reversing the change from bug 295815 in the latest MOZILLA_1_8_BRANCH code did not help. To double-check, I checked out 1.8 branch dated a day before bug 295815 got fixed (does not crash) and after applying the patch it crashes - so it looks like it is a regression from bug 295815 after all.
Blocks: 295815
Comment 22•18 years ago
|
||
Is is possible to identify a trunk build that also did crash? If so can we then identify what fixed the crash?
Updated•17 years ago
|
Assignee: nobody → mats.palmgren
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+
Comment 23•17 years ago
|
||
Doesn't look like we're making progress, moving to next release.
Flags: blocking1.8.1.5+ → blocking1.8.1.6+
Updated•17 years ago
|
Flags: blocking1.8.0.13+ → blocking1.8.0.14+
Updated•17 years ago
|
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.9?
Flags: blocking1.8.1.8+
Flags: blocking1.8.0.14?
Flags: blocking1.8.0.14+
Updated•17 years ago
|
Flags: blocking1.8.0.14? → blocking1.8.0.15?
Updated•17 years ago
|
Flags: blocking1.8.1.12? → blocking1.8.1.12+
Updated•17 years ago
|
Flags: blocking1.8.1.13+
Flags: blocking1.8.1.12-
Flags: blocking1.8.1.12+
Updated•17 years ago
|
Whiteboard: [sg:moderate?] using freed frame → [sg:moderate?][needs patch] using freed frame
Updated•17 years ago
|
Flags: blocking1.8.0.15? → blocking1.8.0.15+
Comment 24•17 years ago
|
||
ditto
Comment 25•17 years ago
|
||
reflow log: VP 03A8E9F0 r=0 a=11900,16837 c=11900,16837 cnt=1653 scroll 03A8EC70 r=0 a=11900,16837 c=11900,16837 cnt=1654 page 03A9CC44 r=0 a=12860,17797 c=12860,UC cnt=1656 block 03A9D368 r=0 a=10460,13732 c=10220,UC cnt=1659 block 03A9DDF8 r=0 a=10220,13732 c=7200,UC cnt=1665 tblO 03A9E054 r=0 a=7200,3022 c=UC,UC cnt=1668 tbl 03A9E1B4 r=0 a=7200,3015 c=7350,UC cnt=1669 rowG 03AA3EAC r=0 a=UC,UC c=UC,UC cnt=1670 row 03A9E5A8 r=0 a=UC,UC c=UC,UC cnt=1671 cell 03A9E778 r=0 a=UC,UC c=UC,UC cnt=1672 block 03A9E7D8 r=0 a=UC,UC c=UC,UC cnt=1673 block 03A9E7D8 d=0,0 me=0 cell 03A9E778 d=30,30 me=30 row 03A9E5A8 d=UC,30 row 03A9E928 r=0 a=UC,UC c=UC,UC cnt=1674 cell 03A9EAF8 r=0 a=UC,UC c=UC,UC cnt=1675 block 03A9EB58 r=0 a=UC,UC c=UC,UC cnt=1676 block 03A9EB58 d=0,2400 me=0 cell 03A9EAF8 d=30,2430 me=30 row 03A9E928 d=UC,2430 rowG 03AA3EAC d=UC,2490 rowG 03AA3EAC r=2 a=7290,2955 c=7290,UC cnt=1686 row 03A9E5A8 r=2 a=7290,UC c=7290,UC cnt=1687 cell 03A9E778 r=2 a=7290,UC c=7260,UC cnt=1688 block 03A9E7D8 r=2 a=7260,UC c=7260,UC cnt=1689 block 03A9E7D8 d=7260,0 me=0 cell 03A9E778 d=7290,30 me=30 row 03A9E5A8 d=7290,30 row 03A9E928 r=2 a=7290,UC c=7290,UC cnt=1690 cell 03A9EAF8 r=2 a=7290,UC c=7260,UC cnt=1691 block 03A9EB58 r=2 a=7260,UC c=7260,UC cnt=1692 block 03A9EB58 d=7260,4500 me=0 cell 03A9EAF8 d=7290,4530 me=30 row 03A9E928 d=7290,4530 row 03A9E928 r=2 a=7290,2895 c=7290,UC cnt=1700 cell 03A9EAF8 r=2 a=7290,2895 c=7260,UC cnt=1701 block 03A9EB58 r=2 a=7260,2865 c=7260,UC cnt=1702 block 03A9EB58 d=7260,4500 me=0 cell 03A9EAF8 d=7290,4530 me=30 row 03A9E928 d=7290,4530 rowG 03AA3EAC d=7290,30 status=0x1o=(0,0) 7290 x 4590 tbl 03A9E1B4 d=7350,90 me=7350 status=0x1 tblO 03A9E054 d=7350,90 me=7350 status=0x1 tblO 03A9E054 r=2 a=7350,3022 c=UC,UC cnt=1712 tbl 03A9E1B4 r=2 a=7350,3015 c=7350,UC cnt=1713 rowG 03AA3EAC r=2 a=7290,2955 c=7290,UC nif=03A8EE90 cnt=1714 row 03A9E5A8 r=2 a=7290,UC c=7290,UC cnt=1715 cell 03A9E778 r=2 a=7290,UC c=7260,UC cnt=1716 block 03A9E7D8 r=2 a=7260,UC c=7260,UC cnt=1717 block 03A9E7D8 d=7260,0 me=0 cell 03A9E778 d=7290,30 me=30 row 03A9E5A8 d=7290,30 row 03A9E928 r=2 a=7290,UC c=7290,UC cnt=1718 cell 03A9EAF8 r=2 a=7290,UC c=7260,UC cnt=1719 block 03A9EB58 r=2 a=7260,UC c=7260,UC cnt=1720 block 03A9EB58 d=7260,4500 me=0 cell 03A9EAF8 d=7290,4530 me=30 row 03A9E928 d=7290,4530 row 03A9E928 r=2 a=7290,2895 c=7290,UC cnt=1728 cell 03A9EAF8 r=2 a=7290,2895 c=7260,UC cnt=1729 block 03A9EB58 r=2 a=7260,2865 c=7260,UC cnt=1730 block 03A9EB58 d=7260,4500 me=0 cell 03A9EAF8 d=7290,4530 me=30 row 03A9E928 d=7290,4530 rowG 03AA3EAC d=7290,30 status=0x1o=(0,0) 7290 x 4590 tbl 03A9E1B4 d=7350,90 me=7350 status=0x1 tblO 03A9E054 d=7350,90 me=7350 status=0x1 block 03A9DDF8 d=7200,14012 status=0x3o=(0,0) 7351 x 14012 block 03A9D368 d=10220,0 status=0x3o=(10219,0) 1 x 280 page 03A9CC44 d=12860,17797 status=0x3 page 03AA51CC r=0 a=12860,17797 c=12860,UC pif=03A9CC44 cnt=1747 block 03AA5148 r=0 a=10460,15397 c=10220,UC pif=03A9D368 cnt=1750 block 03A9DDF8 r=2 a=10220,15397 c=7200,UC cnt=1751 tblO 03A9E054 r=2 a=7200,4687 c=UC,UC nif=03AA5008 cnt=1754 tbl 03A9E1B4 r=2 a=7200,4680 c=7350,UC nif=03AA5058 cnt=1755 rowG 03AA3EAC r=2 a=7290,4620 c=7290,UC nif=03A8EE90 cnt=1756 row 03A9E5A8 r=2 a=7290,UC c=7290,UC cnt=1757 cell 03A9E778 r=2 a=7290,UC c=7260,UC cnt=1758 block 03A9E7D8 r=2 a=7260,UC c=7260,UC cnt=1759 block 03A9E7D8 d=7260,0 me=0 cell 03A9E778 d=7290,30 me=30 row 03A9E5A8 d=7290,30 rowG 03AA3EAC d=7290,30 The interesting stuff happens on the first page the line tblO 03A9E054 r=2 a=7200,4687 c=UC,UC nif=03AA5008 cnt=1754 shows that we reflow on the second page the same table as on the first page instead of the continuing frame 03AA5008 there should be a reference to the pif. What happens then is a quick story we reflow the table again it does fit and we delete the next inflow of the rowgroup which contains the second row. After this a access to the cellmap is expected to crash.
Comment 26•17 years ago
|
||
Martijn, could you help with comment 22.
Comment 27•17 years ago
|
||
Martijn, no need for searching taking bug 347367 fixes the crash
Depends on: 347367
Updated•17 years ago
|
Flags: blocking1.8.1.14? → blocking1.8.1.14+
Comment 28•17 years ago
|
||
fixed by bug 347367 going into branch
Comment 29•17 years ago
|
||
Verified fixed in Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.15pre) Gecko/2008050803 BonEcho/2.0.0.15pre. The crashing no longer occurs as it does when I try the test case in 2.0.0.14.
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Alias: CVE-2008-2798
Updated•16 years ago
|
Alias: CVE-2008-2798
Updated•16 years ago
|
Group: security
Reporter | ||
Comment 30•16 years ago
|
||
fwiw, verified printing html table sample still prints w/out crashing in current release: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Updated•13 years ago
|
Crash Signature: [@ nsCellMap::GetCellInfoAt]
You need to log in
before you can comment on or make changes to this bug.
Description
•