119583 - Crash when try to reload the print preview netscape home page [@ nsPresContext::SetImgAnimations]

Status: VERIFIED WORKSFORME

(Core :: Printing: Output, defect)

Description

[Yuying Long]

Build: 01-10 trunk build on linux RH7.1

Steps:
1. Launch netscape, and go netscape home page: http://home.netscape.com
2. File | Print Preview
3. Will bring up the print preview page.
4. Click on reload icon.

Result:
Crash

Can not attach the talk back data cause seems there is something wrong with the
server right now.

Comment 1

[Yuying Long]

Here is the stack trace, I don't see this crash on other pages right now:

Trigger Reason SIGSEGV: Segmentation Fault: (signal 11) 
Stack Trace  
nsPresContext::SetImgAnimations() 
nsPresContext::SetImgAnimations() 
nsPresContext::SetImgAnimations() 
nsPresContext::SetImgAnimations() 
nsPresContext::SetImgAnimations() 
nsPresContext::SetImgAnimations() 
nsPresContext::SetImgAnimations() 
nsPresContext::SetImageAnimationMode() 
PrintObject::~PrintObject() 
PrintData::~PrintData() 
DocumentViewerImpl::Destroy() 
DocumentViewerImpl::Show() 
PresShell::UnsuppressAndInvalidate() 
PresShell::ProcessReflowCommands() 
HandlePLEvent() 
PL_HandleEvent() 
PL_ProcessPendingEvents() 
nsEventQueueImpl::ProcessPendingEvents() 
event_processor_callback() 
our_gdk_io_invoke() 
libglib-1.2.so.0 + 0x1001e (0x4038d01e) 
libglib-1.2.so.0 + 0x117f3 (0x4038e7f3) 
libglib-1.2.so.0 + 0x11dd9 (0x4038edd9) 
libglib-1.2.so.0 + 0x11f8c (0x4038ef8c) 
libgtk-1.2.so.0 + 0x94803 (0x402a3803) 
nsAppShell::Run() 
nsAppShellService::Run() 
netscape-bin + 0x8099 (0x08050099) 
netscape-bin + 0x8907 (0x08050907) 
libc.so.6 + 0x1c177 (0x404d9177) 

Comment 2

[Chu Alan]

Another crash-on-reload page : http://www.uhome.net/

Comment 3

[Chu Alan]

is this a dup of bug 119372 ?

Comment 4

[rods (gone)]

Attachment: trace of where frames are being deleted

I get this assert several time while trying to "Print Preview" the page, but I
do not get it when I am trying to print the page. There seems to be something
really flakey about this page.

When it crashes then I get this stack trace trying to turn back on the animated
images, but at this point I think the frame tree is hosed:
CallQueryInterface(nsIFrame * 0x04d00018, nsIImageFrame * * 0x0012d004) line
270 + 19 bytes
nsPresContext::SetImgAnimations(nsCOMPtr<nsIContent> & {...}, unsigned short 0)
line 880 + 13 bytes
nsPresContext::SetImgAnimations(nsCOMPtr<nsIContent> & {...}, unsigned short 0)
line 896
nsPresContext::SetImgAnimations(nsCOMPtr<nsIContent> & {...}, unsigned short 0)
line 896
nsPresContext::SetImgAnimations(nsCOMPtr<nsIContent> & {...}, unsigned short 0)
line 896
nsPresContext::SetImgAnimations(nsCOMPtr<nsIContent> & {...}, unsigned short 0)
line 896
nsPresContext::SetImgAnimations(nsCOMPtr<nsIContent> & {...}, unsigned short 0)
line 896
nsPresContext::SetImgAnimations(nsCOMPtr<nsIContent> & {...}, unsigned short 0)
line 896
nsPresContext::SetImageAnimationMode(nsPresContext * const 0x042fdcf0, unsigned
short 0) line 921
PrintObject::~PrintObject() line 874
PrintObject::`scalar deleting destructor'(unsigned int 1) + 15 bytes
PrintData::~PrintData() line 795 + 31 bytes
PrintData::`scalar deleting destructor'(unsigned int 1) + 15 bytes

Comment 5

[rods (gone)]

*** This bug has been marked as a duplicate of 114139 ***

Comment 6

[sujay]

verified.

Comment 7

[Yuying Long]

Re-open - still see this crash ( stack track ID 1780706 which is same crash as
in original report) on 01-17 trunk build while bug 114139 has been fixed.  

Note this one is linux only and bug 114139 is for all platforms.

Comment 8

[sujay]

confirming...I also see this crash after hitting reload using 1/17 build.

follow the exact steps....

Comment 9

[greer]

Marking this one with topcrash, so the talkback reports point to this bug.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think the patch below might fix this, although I'm inclined to think it won't
(but see below).  nsPresContext::SetImgAnimations doesn't check the return value
of GetPrimaryFrameFor, and GetPrimaryFrameFor doesn't null out the return value
in all failure cases.  However, the only failure case that would be possible
here is if we'd already called the pres shell's Destroy, which doesn't seem like
the case based on this stack, although I could be wrong (and it's a bit
complicated).  If this crash stack could happen after the pres shell's Destroy
has been called, then this patch would be a likely fix.

Index: nsFrameManager.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/base/src/nsFrameManager.cpp,v
retrieving revision 1.101
diff -u -r1.101 nsFrameManager.cpp
--- nsFrameManager.cpp	11 Jan 2002 20:10:38 -0000	1.101
+++ nsFrameManager.cpp	22 Jan 2002 16:32:21 -0000
@@ -602,10 +602,9 @@
 NS_IMETHODIMP
 FrameManager::GetPrimaryFrameFor(nsIContent* aContent, nsIFrame** aResult)
 {
+  *aResult = nsnull;  // initialize out param
   NS_ENSURE_TRUE(mPresShell, NS_ERROR_NOT_AVAILABLE);
-  NS_ENSURE_ARG_POINTER(aResult);
   NS_ENSURE_ARG_POINTER(aContent);
-  *aResult = nsnull;  // initialize out param
 
   nsresult rv;
   if (mPrimaryFrameMap.ops) {

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually, never mind.  I see your comment about the assertions, and those are a
far more likely explanation for the crash.  (And, as I mentioned before to Marc,
maybe we should change the design a little and make removal from the primary
frame map happen in NotifyDestroyingFrame instead of where it does now so that
we don't have these problems.)

Comment 12

[rods (gone)]

This works for me. It may have been fixed by my checkin last night. reopen if
this still crashes with today's build.

Comment 13

[Jan Carpenter]

Marking verified.