Closed
Bug 215660
Opened 22 years ago
Closed 20 years ago
Browser crashes when trying to print this page [@ nsBandTrapezoid::operator=(nsRect const&)]
Categories
(Core :: Printing: Output, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jliebson, Unassigned)
References
()
Details
(Keywords: hang, regression, testcase)
Attachments
(2 files, 1 obsolete file)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Load the page, try to print to LJ4, print dialog appears, click on "OK",
Firebird's progress box appears. Wait a while, click on the "X", as nothing is
happening. Get error message that program is not responding, and it closes.
Same problem exists, on this same pge, in Mozilla 1.4, Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Reproducible: Always
Steps to Reproduce:
1. Please see "Details" above, for the details _are_ the problem.
2.
3.
Actual Results:
Program shut down.
Expected Results:
Should have printed the page.
Comment 1•22 years ago
|
||
this testcase crashes linux trunk 2003080805 on print and print preview
Comment 2•22 years ago
|
||
Comment on attachment 129521 [details]
testcase
testcase is bug 185357, but this bug is not a dupe of that.
Attachment #129521 -
Attachment is obsolete: true
Comment 3•22 years ago
|
||
testcase for this bug.
hangs linux trunk 2003080805 on print or print preview
Comment 4•22 years ago
|
||
Comment 5•22 years ago
|
||
regression between linux trunk 2002092408 and 2002092511, probably bug 169620
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Updated•21 years ago
|
Summary: Browser crashes when trying to print this page. → Browser crashes when trying to print this page [@ nsBandTrapezoid::operator=(nsRect const&)]
Comment 6•21 years ago
|
||
Successfully crashes on:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040630
Firefox/0.8.0+
Reporter | ||
Comment 7•21 years ago
|
||
Still crashes ("successfully"!) with Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Comment 8•20 years ago
|
||
I confimed.
Here is the back trace.
#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
Comment 9•20 years ago
|
||
I'm sorry, I made a mistake. I wanted to comment in bug 244665.
Reporter | ||
Comment 10•20 years ago
|
||
This page crashes Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0: http://www.tedsimages.com/text/pvpenin.htm
When I try to print it, the 'Preparing" box pops up, whereupon all action stops
and Firefox stops responding. FF does not close. This is identical to the
behavior of the first such page I reported in this Bugzillla entry.
Comment 11•20 years ago
|
||
WORKSFORME in current 20050324 trunk build. Please reopen if you can still see
the issue with this build or newer builds.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•