bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Crash while loading www.tomshardware.com - ASSERTION: didn't find view in nsHTMLContainerFrame.cpp

RESOLVED DUPLICATE of bug 59426

Status

()

Core
Layout
P1
critical
RESOLVED DUPLICATE of bug 59426
18 years ago
18 years ago

People

(Reporter: u12623, Assigned: Chris Waterson)

Tracking

({crash, topcrash})

Trunk
crash, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
[ 2000-11-17-20-cvs linux-2.4.0-test10 i686 SMP]

Steps to reproduce:
1. fire up mozilla
2. load http://www.tomshardware.com/

result: browser crashes

NOTE: if it doesn't crash, clear mem & disk cache & flush the memory, then
file--> quit and this time it'll crash

here is the console output:

###!!! ASSERTION: didn't find view: 'aOldParentFrame && aNewParentFrame', file
nsHTMLContainerFrame.cpp, line 356
###!!! Break: at file nsHTMLContainerFrame.cpp, line 356

cc'ing dbaron@fas.harvard.edu since he has made the last changes to
nsHTMLContainerFrame.cpp
A stack trace for the assertion would be useful.  This may be related to the
inline inside block crashes waterson is working on.
I crashed also on this page.

build 2000111604 on W2k.
Talkback ID : TB21204920Z
(Reporter)

Comment 3

18 years ago
(build-date on first comment is wrong; should read 2000-11-16, of course)

Here is the stack trace using cvs-build from 2000-11-17-21 GMT+1:

###!!! ASSERTION: didn't find view: 'aOldParentFrame && aNewParentFrame', file
nsHTMLContainerFrame.cpp, line 356
###!!! Break: at file nsHTMLContainerFrame.cpp, line 356

Program received signal SIGSEGV, Segmentation fault.
0x41307544 in nsHTMLContainerFrame::ReparentFrameViewList
(aPresContext=0x427c3678, aChildFrameList=0x42f71c20,
aOldParentFrame=0x42d2203c, aNewParentFrame=0x0) at nsHTMLContainerFrame.cpp:365
365           aNewParentFrame->GetView(aPresContext, &newParentView);
(gdb) bt
#0  0x41307544 in nsHTMLContainerFrame::ReparentFrameViewList
(aPresContext=0x427c3678, aChildFrameList=0x42f71c20,
aOldParentFrame=0x42d2203c, aNewParentFrame=0x0) at nsHTMLContainerFrame.cpp:365
#1  0x414803c0 in MoveChildrenTo (aPresContext=0x427c3678,
aNewParentSC=0x42d50250, aNewParent=0x42f71ccc, aFrameList=0x42f71c20) at
nsCSSFrameConstructor.cpp:438
#2  0x414b334b in nsCSSFrameConstructor::SplitToContainingBlock
(this=0x424c0600, aPresContext=0x427c3678, aState=@0xbffff34c,
aFrame=0x42d222c4, aLeftInlineChildFrame=0x42f716f4,
aBlockChildFrame=0x42f71c20, aRightInlineChildFrame=0x42f71c94,
    aTransfer=0) at nsCSSFrameConstructor.cpp:13073
#3  0x414aa491 in nsCSSFrameConstructor::CantRenderReplacedElement
(this=0x424c0600, aPresShell=0x42b23480, aPresContext=0x427c3678,
aFrame=0x42d222c4) at nsCSSFrameConstructor.cpp:10679
#4  0x4167e7c8 in StyleSetImpl::CantRenderReplacedElement (this=0x42424238,
aPresContext=0x427c3678, aFrame=0x42d222c4) at nsStyleSet.cpp:1247
#5  0x412ff28f in FrameManager::HandlePLEvent (aEvent=0x42d14bc0) at
nsFrameManager.cpp:870
#6  0x400f2716 in PL_HandleEvent (self=0x42d14bc0) at plevent.c:576
#7  0x400f2569 in PL_ProcessPendingEvents (self=0x80a9bc8) at plevent.c:509
#8  0x400f449b in nsEventQueueImpl::ProcessPendingEvents (this=0x80a9ba0) at
nsEventQueue.cpp:356
#9  0x406add59 in event_processor_callback (data=0x80a9ba0, source=6,
condition=GDK_INPUT_READ) at nsAppShell.cpp:158
#10 0x406ad9d6 in our_gdk_io_invoke (source=0x40f738b8, condition=G_IO_IN,
data=0x40f738a8) at nsAppShell.cpp:58
#11 0x40878049 in g_io_unix_dispatch () from /usr/local/lib/libglib-1.2.so.0
#12 0x40879806 in g_main_dispatch () from /usr/local/lib/libglib-1.2.so.0
#13 0x40879e33 in g_main_iterate () from /usr/local/lib/libglib-1.2.so.0
#14 0x40879fec in g_main_run () from /usr/local/lib/libglib-1.2.so.0
#15 0x4079da1b in gtk_main () from /usr/local/lib/libgtk-1.2.so.0
#16 0x406aea92 in nsAppShell::Run (this=0x80a6f98) at nsAppShell.cpp:335
#17 0x405c97bb in nsAppShellService::Run (this=0x80b45d8) at
nsAppShellService.cpp:407
#18 0x8052dc1 in main1 (argc=1, argv=0xbffff96c, nativeApp=0x0) at
nsAppRunner.cpp:1015
#19 0x80537fb in main (argc=1, argv=0xbffff96c) at nsAppRunner.cpp:1255
->Waterson for investigation, since he's working on crashes in the same function.
Assignee: pollmann → waterson
Component: HTMLFrames → Layout
Keywords: crash

Comment 5

18 years ago
This should be set to OS: ALL (same is observed on Windows' systems).

I first observed this with the 2000 11 06 build but it came up only on the 16 of
november. It seems that something new was introduced in the page on that time. I
might be useful to same a copy of this page now before it is too late. Will see
if I can create the attachement properly.
(Reporter)

Comment 6

18 years ago
[ OS: Linux --> ALL]

as per Patrick's comment
OS: Linux → All

Comment 7

18 years ago
Created attachment 19423 [details]
page source with web sniffer in case the phenomenon disappears
(Reporter)

Comment 8

18 years ago
[ 2000-11-17-23-cvs GMT+1 ]

I noticed something: it doesn't crash anymore with memory-cache disabled, but
with memory-cache enabled, it crashes all the time after clearing the
memory-cache. I have disk & XUL-cache disabled all the time.

Comment 9

18 years ago
This is a duplicate of bug 59426. The fix is in bug 57026.

Comment 10

18 years ago
*** Bug 60601 has been marked as a duplicate of this bug. ***
*** Bug 60767 has been marked as a duplicate of this bug. ***

Comment 12

18 years ago
Did not crash a few days ago (cannnot give exact date), but I visited that site
and don't remember mozilla crashing on me.

Comment 13

18 years ago
moving to P1 since this is showing up in the top crash list as well.
tomshardware isn't the only url causing this crash (assuming it really is the
same one in the topcrash logs.)  From the logs, the reported stack trace is:
         nsHTMLContainerFrame::ReparentFrameViewList()
	 MoveChildrenTo()
	 nsCSSFrameConstructor::SplitToContainingBlock()
	 nsCSSFrameConstructor::CantRenderReplacedElement()
	 StyleSetImpl::CantRenderReplacedElement()
	 FrameManager::HandlePLEvent()
	 PL_HandleEvent()
	 PL_ProcessPendingEvents()
	 nsEventQueueImpl::ProcessPendingEvents()
	 event_processor_callback()
	 our_gdk_io_invoke()
	 libglib-1.2.so.0 + 0xecd9 (0x404accd9)
	 nsHTMLContainerFrame::ReparentFrameViewList()
	 MoveChildrenTo()
	 nsCSSFrameConstructor::SplitToContainingBlock()
	 nsCSSFrameConstructor::CantRenderReplacedElement()
	 StyleSetImpl::CantRenderReplacedElement()
	 FrameManager::HandlePLEvent()
	 PL_HandleEvent()
	 PL_ProcessPendingEvents()
	 nsEventQueueImpl::ProcessPendingEvents()
	 event_processor_callback()
	 our_gdk_io_invoke()
	 libglib-1.2.so.0 + 0xecd9 (0x404accd9)

Chris, if the top crash stack I've included here is actually a different
problem, please split it out into a separate bug.  Thanks!  But it sure looks
like the one entered From Jan Lippuner 2000-11-17 13:09.
Keywords: topcrash
Priority: P3 → P1

Comment 14

18 years ago
*** Bug 61598 has been marked as a duplicate of this bug. ***

Comment 15

18 years ago
dup of topcrash

*** This bug has been marked as a duplicate of 59426 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.