Closed Bug 244665 Opened 20 years ago Closed 19 years ago

print/print preview crashes on page with long nested tables [@ nsBlockFrame::PullFrameFrom]

Tracking

()

Status:

VERIFIED FIXED

People

(Reporter: mozilla, Unassigned)

Details

(Keywords: testcase)

Attachments

(2 files, 1 obsolete file)

large testcase - needs more reducing to isolate problem 20 years ago James Napolitano 27.48 KB, text/html		Details
TB60528X 20 years ago Stephen Donner [:stephend] Not actively reading bugmail 8.84 KB, text/plain		Details
minimized testcase! 20 years ago James Napolitano 486 bytes, text/html		Details

James Napolitano

Reporter

Description

•

20 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040514
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040514

In bug 234414, someone submitted an example of a page with a complex collection
of nested tables that crashes on print preview.  Investigating that page here,
since it looks like a somewhat different that what that bug report focused on.  

Reproducible: Always
Steps to Reproduce:
1. Load testcase
2. Print Preview


Actual Results:  
*crash!*

Expected Results:  
no crash

Testcase and stacktrace to follow.

James Napolitano

Reporter

Comment 1

•

20 years ago

Attached file large testcase - needs more reducing to isolate problem (obsolete) — Details

James Napolitano

Reporter

Comment 2

•

20 years ago

You can see a stacktrace (from about a month ago) at
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB28084H.
This page still crashes on Moz 1.7rc2.

Stephen Donner [:stephend] Not actively reading bugmail

Comment 3

•

20 years ago

With the current 1.8 trunk build 2004-05-25-09 on Windows XP, I get a totally
different stack trace.

Stephen Donner [:stephend] Not actively reading bugmail

Comment 4

•

20 years ago

Attached file TB60528X — Details

Boris Zbarsky [:bzbarsky]

Comment 5

•

20 years ago

Stephend, is there any local variable data?  The only way that code should be
crashing is if we're working with deleted objects... (and a minimal testcase
would go a long way to determining whether that is the case).

Stephen Donner [:stephend] Not actively reading bugmail

Comment 6

•

20 years ago

If there is local data, I don't know how to extract it from my view of
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB60528X.

Jay, any chance you could help us with a full Talkback report, perhaps with
registers?

Jay Patel [:jay]

Comment 7

•

20 years ago

I tried to look up the parameters in the detailed Talkback reports, but got a
bunch of "not availables":

nsStyleContext::GetStyleData
  this = Register variable - data not available
  aSID = Data not available

IsPercentageAwareChild
  aFrame = Data not available

nsBlockFrame::ReflowInlineFrame
  this = Register variable - data not available
  aState = Data not available
  aLineLayout = Data not available
  aLine = {nsLineList_iterator}
     mCurrent = Data not available
  aFrame = Data not available
  aLineReflowStatus = Data not available
  frameReflowStatus = Data not available
  rv = Data not available
  pushedFrame = Data not available
  breakType = Data not available
  madeContinuation = Data not available
  frameType = Data not available
  madeContinuation = Data not available

But here is the register info if you guys know how to figure that out:

Registers:
EAX:	60466504 	EBX:	0012c6ac 	ECX:	00000000 	EDX:	00000004
ESI:	0000000f 	EDI:	00020008 	ESP:	0012f898 	EBP:	0012f944
EIP:	60d5bd95 	cf PF af ZF sf of IF df nt RF vm   IOPL: 0
CS:	001b	DS:	0023	SS:	0023	ES:	0023	FS:	0038	GS:	0000

Hiroyuki Ikezoe (:hiro)

Comment 8

•

20 years ago

#0  0x0000002a973963b9 in kill () from /lib/libc.so.6
(gdb) bt
#0  0x0000002a973963b9 in kill () from /lib/libc.so.6
#1  0x0000002a95bbf73b in pthread_kill () from /lib/libpthread.so.0
#2  0x0000002a95bbfa52 in raise () from /lib/libpthread.so.0
#3  0x0000002a9df8298f in nsProfileLock::FatalSignalHandler(int) (
    signo=11) at nsProfileLock.cpp:205
#4  0x0000002a95bc1d4e in __pthread_sighandler ()
   from /lib/libpthread.so.0
#5  <signal handler called>
#6  0x0000002a9bd3b882 in nsIFrame::GetNextSibling() const (
    this=0xfcd38570) at nsIFrame.h:683
#7  0x0000002a9bd439fc in nsBlockFrame::PullFrameFrom(nsBlockReflowState&,
nsLineBox*, nsLineList&, nsLineList_iterator, int, int, nsIFrame*&) (
    this=0x1c71ff0, aState=@0x7fbfff9570, aLine=0x1c697a0, 
    aFromContainer=@0x1c72058, aFromLine=
      {mCurrent = 0x1c73e20, mListLink = 0x1c72058}, 
    aUpdateGeometricParent=0, aDamageDeletedLines=0, 
    aFrameResult=@0x7fbfff8988) at nsBlockFrame.cpp:2569
#8  0x0000002a9bd4381a in nsBlockFrame::PullFrame(nsBlockReflowState&,
nsLineList_iterator, int, nsIFrame*&) (this=0x1c71ff0, 
    aState=@0x7fbfff9570, aLine=
      {mCurrent = 0x1c697a0, mListLink = 0x1c72058}, 
    aDamageDeletedLines=0, aFrameResult=@0x7fbfff8988)
    at nsBlockFrame.cpp:2502
#9  0x0000002a9bd45859 in
nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState&, nsLineLayout&,
nsLineList_iterator, int*, unsigned char*, int, int) (this=0x1c71ff0,
aState=@0x7fbfff9570, aLineLayout=@0x7fbfff8a60, 
    aLine={mCurrent = 0x1c697a0, mListLink = 0x1c72058}, 
    aKeepReflowGoing=0x7fbfff9308, 
    aLineReflowStatus=0x7fbfff906b "\002", aUpdateMaximumWidth=1, 
    aDamageDirtyArea=0) at nsBlockFrame.cpp:3464
#10 0x0000002a9bd4530f in
nsBlockFrame::DoReflowInlineFramesAuto(nsBlockReflowState&, nsLineList_iterator,
int*, unsigned char*, int, int) (
    this=0x1c71ff0, aState=@0x7fbfff9570, aLine=
      {mCurrent = 0x1c697a0, mListLink = 0x1c72058}, 
    aKeepReflowGoing=0x7fbfff9308, 
    aLineReflowStatus=0x7fbfff906b "\002", aUpdateMaximumWidth=1, 
    aDamageDirtyArea=0) at nsBlockFrame.cpp:3333
#11 0x0000002a9bd4508e in nsBlockFrame::ReflowInlineFrames(nsBlockReflowState&,
nsLineList_iterator, int*, int, int) (this=0x1c71ff0, 
    aState=@0x7fbfff9570, aLine=
      {mCurrent = 0x1c697a0, mListLink = 0x1c72058}, 
    aKeepReflowGoing=0x7fbfff9308, aDamageDirtyArea=0, 
    aUpdateMaximumWidth=1) at nsBlockFrame.cpp:3277
#12 0x0000002a9bd434c8 in nsBlockFrame::ReflowLine(nsBlockReflowState&,
nsLineList_iterator, int*, int) (this=0x1c71ff0, aState=@0x7fbfff9570, 
    aLine={mCurrent = 0x1c697a0, mListLink = 0x1c72058}, 
    aKeepReflowGoing=0x7fbfff9308, aDamageDirtyArea=0)
---Type <return> to continue, or q <return> to quit---q
 at nsBlockFrame.cpQuit
(gdb) frame 7
#7  0x0000002a9bd439fc in nsBlockFrame::PullFrameFrom(nsBlockReflowState&,
nsLineBox*, nsLineList&, nsLineList_iterator, int, int, nsIFrame*&) (
    this=0x1c71ff0, aState=@0x7fbfff9570, aLine=0x1c697a0, 
    aFromContainer=@0x1c72058, aFromLine=
      {mCurrent = 0x1c73e20, mListLink = 0x1c72058}, 
    aUpdateGeometricParent=0, aDamageDeletedLines=0, 
    aFrameResult=@0x7fbfff8988) at nsBlockFrame.cpp:2569
2569          fromLine->mFirstChild = frame->GetNextSibling();
(gdb) list
2564        
2565        if (0 != --fromLineChildCount) {
2566          // Mark line dirty now that we pulled a child
2567          fromLine->SetChildCount(fromLineChildCount);
2568          fromLine->MarkDirty();
2569          fromLine->mFirstChild = frame->GetNextSibling();
2570        }
2571        else {
2572          // Free up the fromLine now that it's empty
2573          // Its bounds might need to be redrawn, though.
(gdb) p fromLineChildCount
$1 = -1

James Napolitano

Reporter

Comment 9

•

20 years ago

Attached file minimized testcase! — Details

I cut the HTML that causes the crash down to a few lines.  The culprit is four
consecutive style="page-break-before: always" blocks within a table cell. Just
hit print preview and both SeakMonkey and FireFox 1.0 Preview Release will
crash.

James Napolitano

Reporter

Updated

•

20 years ago

Attachment #149292 - Attachment is obsolete: true

James Napolitano

Reporter

Updated

•

20 years ago

Keywords: testcase

Version: Other Branch → Trunk

James Napolitano

Reporter

Updated

•

20 years ago

Summary: print/print preview crashes on page with long nested tables → print/print preview crashes on page with long nested tables [@ nsBlockFrame::PullFrameFrom]

James Napolitano

Reporter

Comment 10

•

20 years ago

My talkback ID from the testcase is 1022528H, viewable at
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=1022528H
It has a similar stacktrace to the one in comment 4, but it places the actual
crash at nsBlockFrame::PullFrameFrom instead of nsStyleContext::GetStyleData.

Stephen Donner [:stephend] Not actively reading bugmail

Comment 11

•

20 years ago

This my recently-filed bug 262403 are probably very similar, if not DUPs, but
this bug has the minimal testcase.

Robert O'Callahan (:roc) (email my personal email if necessary)

Comment 12

•

20 years ago

My columns patch changes this code quite a bit. I'll come back to this after
columns has landed (remind me if I forget)

Hermann Schwab

Comment 13

•

20 years ago

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a6) Gecko/20041126
both testcases tested in preview

Stephen Donner [:stephend] Not actively reading bugmail

Comment 14

•

20 years ago

Me too; I no longer crash or hang at all with
https://bugzilla.mozilla.org/attachment.cgi?id=160439

James, same for you?

This is with build 2005-01-22-05, Windows XP trunk.

Bernd

Comment 15

•

19 years ago

Robert this is a reminder:
> I'll come back to this after columns has landed (remind me if I forget)

This is wfm winxp 2005021614

Robert O'Callahan (:roc) (email my personal email if necessary)

Comment 16

•

19 years ago

Okay, let's pretend I fixed it :-)

Status: NEW → RESOLVED

Closed: 19 years ago

Resolution: --- → FIXED

Stephen Donner [:stephend] Not actively reading bugmail

Comment 17

•

19 years ago

Verified FIXED using build 2005-02-24-05 with the testcase at
https://bugzilla.mozilla.org/attachment.cgi?id=160439 on Windows XP Seamonkey trunk.

Status: RESOLVED → VERIFIED

You need to log in before you can comment on or make changes to this bug.