Closed Bug 60397 Opened 24 years ago Closed 24 years ago

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

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 59426

People

(Reporter: u12623, Assigned: waterson)

References

(
URL
)

Details

(Keywords: crash, topcrash)

Attachments

(1 file)

page source with web sniffer in case the phenomenon disappears
530.72 KB, text/html
Details 
[ 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
(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
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.

[ OS: Linux --> ALL]

as per Patrick's comment
OS: Linux → All
[ 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.
This is a duplicate of bug 59426. The fix is in bug 57026.
*** Bug 60601 has been marked as a duplicate of this bug. ***
*** Bug 60767 has been marked as a duplicate of this bug. ***
Did not crash a few days ago (cannnot give exact date), but I visited that site
and don't remember mozilla crashing on me.
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
*** Bug 61598 has been marked as a duplicate of this bug. ***
dup of topcrash

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

Attachment

General

Creator:
Created:
Updated:
Size: