The default bug view has changed. See this FAQ.

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

VERIFIED FIXED

Status

()

Core
Layout: Tables
--
critical
VERIFIED FIXED
10 years ago
6 years ago

People

(Reporter: Devon Hubbard, Assigned: mats)

Tracking

(4 keywords)

1.8 Branch
crash, regression, testcase, verified1.8.1.15
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1.12 -
blocking1.8.1.13 -
blocking1.8.1.15 +
wanted1.8.1.x +
blocking1.8.0.next +
wanted1.8.0.x +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:moderate?][needs patch] using freed frame, crash signature, URL)

Attachments

(5 attachments)

(Reporter)

Description

10 years ago
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

10 years ago
Created attachment 262126 [details]
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.
(Reporter)

Comment 2

10 years ago
Created attachment 262128 [details]
Vista xps print output of sample page

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

Comment 3

10 years ago
Created attachment 262129 [details]
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.
(Reporter)

Comment 4

10 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
Do you have also a Talkback ID from this crashs ? (http://kb.mozillazine.org/Talkback)
(Reporter)

Comment 6

10 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

10 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

10 years ago
minor typo correction: "The offending table data is..."
(Reporter)

Comment 9

10 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

10 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

10 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

10 years ago
Created attachment 262341 [details]
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.
(Assignee)

Comment 12

10 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

10 years ago
Summary: Printing crash in nsTableCellMap(); Exception: EXC_BAD_INSTRUCTION (0x0002) → Printing crash [@ nsCellMap::GetCellInfoAt] Exception: EXC_BAD_INSTRUCTION (0x0002)
(Assignee)

Comment 13

10 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.
OS: Mac OS X → All
Hardware: Macintosh → All
(Assignee)

Comment 14

10 years ago
Created attachment 262355 [details]
Testcase #1
(Assignee)

Updated

10 years ago
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?

Comment 16

10 years ago
Mats does this crash trunk?
(Assignee)

Comment 17

10 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

10 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

10 years ago
my guess would then be bug 295815
(Assignee)

Comment 20

10 years ago
Backing out bug 295815 did not help. Same crash.
(Assignee)

Comment 21

10 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
Keywords: crash

Comment 22

10 years ago
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

Comment 25

9 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

9 years ago
Martijn, could you help with comment 22.

Comment 27

9 years ago
Martijn, no need for searching taking bug 347367 fixes the crash
Depends on: 347367
Flags: blocking1.8.1.14? → blocking1.8.1.14+

Comment 28

9 years ago
fixed by bug 347367 going into branch
Status: NEW → RESOLVED
Last Resolved: 9 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
Keywords: fixed1.8.1.15, qawanted → verified1.8.1.15
Alias: CVE-2008-2798
Alias: CVE-2008-2798
Group: security
(Reporter)

Comment 30

8 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
Crash Signature: [@ nsCellMap::GetCellInfoAt]
You need to log in before you can comment on or make changes to this bug.