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

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect)

Description

[Devon Hubbard]

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.

Comment 1

[Devon Hubbard]

Attachment: crashlogs and web complete page sample that causes crash

The attached *.zip file contains crashlogs, and a web complete *.html page and files that crash Firefox everytime when a print is attempted.

Comment 2

[Devon Hubbard]

Attachment: Vista xps print output of sample page

Win Vista xps output of sample page (what print output should look like)

Comment 3

[Devon Hubbard]

Attachment: Safari printed PDF output of sample page

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 4

[Devon Hubbard]

Comment on attachment 262126 [details]
crashlogs and web complete page sample that causes crash

updated comment on crashlogs and sample page attachment.

Comment 5

[Carsten Book [:Tomcat]]

Do you have also a Talkback ID from this crashs ? (http://kb.mozillazine.org/Talkback)

Comment 6

[Devon Hubbard]

Talkback (v2.0.0.3) add-on is installed and enabled.  Talkback never activates and/or catches the crash though.

Comment 7

[Devon Hubbard]

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.

Comment 8

[Devon Hubbard]

minor typo correction: "The offending table data is..."

Comment 9

[Devon Hubbard]

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

[timeless]

if you can reduce the crash to a smaller file, please attach that crashing reduced testcase, thanks.

Comment 11

[Mats Palmgren (inactive)]

Attachment: 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.

Comment 12

[Mats Palmgren (inactive)]

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

Comment 13

[Mats Palmgren (inactive)]

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.

Comment 14

[Mats Palmgren (inactive)]

Attachment: Testcase #1

Comment 15

[Daniel Veditz [:dveditz]]

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?)

Comment 16

[Bernd]

Mats does this crash trunk?

Comment 17

[Mats Palmgren (inactive)]

(In reply to comment #16)
> Mats does this crash trunk?

No, it's branch only AFAICT (tested Linux and MacOSX).

Comment 18

[Mats Palmgren (inactive)]

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

Comment 19

[Bernd]

my guess would then be bug 295815

Comment 20

[Mats Palmgren (inactive)]

Backing out bug 295815 did not help. Same crash.

Comment 21

[Mats Palmgren (inactive)]

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.

Comment 22

[Bernd]

Is is possible to identify a trunk build that also did crash? If so can we then identify what fixed the crash?

Comment 23

[Daniel Veditz [:dveditz]]

Doesn't look like we're making progress, moving to next release.

Comment 24

[Daniel Veditz [:dveditz]]

ditto

Comment 25

[Bernd]

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

[Bernd]

Martijn, could you help with comment 22.

Comment 27

[Bernd]

Martijn, no need for searching taking bug 347367 fixes the crash

Comment 28

[Bernd]

fixed by bug 347367 going into branch

Comment 29

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 30

[Devon Hubbard]

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