Closed Bug 378027 Opened 13 years ago Closed 12 years ago

Printing crash [@ nsCellMap::GetCellInfoAt] Exception: EXC_BAD_INSTRUCTION (0x0002)

Categories

(Core :: Layout: Tables, defect, critical)

1.8 Branch
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: devonhub, Assigned: mats)

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.
The attached *.zip file contains crashlogs, and a web complete *.html page and files that crash Firefox everytime when a print is attempted.
Win Vista xps output of sample page (what print output should look like)
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.
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
Do you have also a Talkback ID from this crashs ? (http://kb.mozillazine.org/Talkback)
Talkback (v2.0.0.3) add-on is installed and enabled.  Talkback never activates and/or catches the crash though.
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.
minor typo correction: "The offending table data is..."
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.  :-)
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
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
Attached file stack + data
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.
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
Summary: Printing crash in nsTableCellMap(); Exception: EXC_BAD_INSTRUCTION (0x0002) → Printing crash [@ nsCellMap::GetCellInfoAt] Exception: EXC_BAD_INSTRUCTION (0x0002)
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.
OS: Mac OS X → All
Hardware: Macintosh → All
Attached file Testcase #1
Keywords: testcase
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
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
Mats does this crash trunk?
(In reply to comment #16)
> Mats does this crash trunk?

No, it's branch only AFAICT (tested Linux and MacOSX).
my guess would then be bug 295815
Backing out bug 295815 did not help. Same crash.
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
Keywords: crash
Is is possible to identify a trunk build that also did crash? If so can we then identify what fixed the crash?
Assignee: nobody → mats.palmgren
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+
Doesn't look like we're making progress, moving to next release.
Flags: blocking1.8.1.5+ → blocking1.8.1.6+
Flags: blocking1.8.0.13+ → blocking1.8.0.14+
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+
Flags: blocking1.8.0.14? → blocking1.8.0.15?
Flags: blocking1.8.1.12? → blocking1.8.1.12+
Flags: blocking1.8.1.13+
Flags: blocking1.8.1.12-
Flags: blocking1.8.1.12+
Whiteboard: [sg:moderate?] using freed frame → [sg:moderate?][needs patch] using freed frame
Flags: blocking1.8.0.15? → blocking1.8.0.15+
ditto
Flags: blocking1.8.1.14?
Flags: blocking1.8.1.13-
Flags: blocking1.8.1.13+
Keywords: qawanted
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.
Martijn, could you help with comment 22.
Martijn, no need for searching taking bug 347367 fixes the crash
Depends on: 347367
Flags: blocking1.8.1.14? → blocking1.8.1.14+
fixed by bug 347367 going into branch
Status: NEW → RESOLVED
Closed: 12 years ago
Keywords: fixed1.8.1.14
Resolution: --- → FIXED
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
Alias: CVE-2008-2798
Alias: CVE-2008-2798
Group: security
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
Crash Signature: [@ nsCellMap::GetCellInfoAt]
You need to log in before you can comment on or make changes to this bug.