64585 - Browser crashes on leaving a page running JavaScript

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P1)

Description

[Chris Casciano]

I've consistantly had problems with mozilla nightlies crashing when they leave a 
page that has any continually looping javascript [scripts using setTimeout to 
call themselves]

In addition to the URL given above this is the case on all the pages in the 
following directory:
http://placenamehere.com/libraryDoodles/

Comment 1

[Chris Casciano]

to add... this has been happening with all recent nighlies I've tried, incuding 
the one available this morning... 2001-01-07

Comment 2

[Boris Zbarsky [:bzbarsky]]

OK, I see this with a cvs build from 2001-01-05 on Linux.  OS -> All, over to
layout based on the stack trace:

#0  0x40440080 in letters () at ../../../dist/include/nsIPageSequenceFrame.h:112
#1  0x413e3aa5 in PresShell::~PresShell (this=Cannot access memory at address
0x2f498e0c
) at nsPresShell.cpp:1319
Cannot access memory at address 0x2f498e04

Comment 3

[Chris Petersen]

Changing component

Comment 4

[Phil Schwartau]

Searchable stack trace (details will be attached below):


PresShell::~PresShell()
PresShell::`scalar deleting destructor'()
PresShell::Release()
nsCOMPtr<nsIPresShell>::~nsCOMPtr<nsIPresShell>()
nsComputedDOMStyle::~nsComputedDOMStyle()
nsComputedDOMStyle::`scalar deleting destructor'(unsigned int 1)
nsComputedDOMStyle::Release()
nsJSUtils::nsGenericFinalize()
FinalizeCSSStyleDeclaration()
js_FinalizeObject()
js_GC()
js_ForceGC()
JS_GC()
nsJSContext::GC()
GlobalWindowImpl::SetNewDocument()
DocumentViewerImpl::Init()
nsDocShell::SetupNewViewer()
nsWebShell::SetupNewViewer()
nsDocShell::Embed()
nsWebShell::Embed()
nsDocShell::CreateContentViewer()
nsDSURIContentListener::DoContent()
nsDocumentOpenInfo::DispatchContent()
nsDocumentOpenInfo::OnStartRequest()
nsHTTPFinalListener::OnStartRequest()
nsHTTPCacheListener::OnStartRequest()
nsDiskCacheRecordChannel::OnStartRequest()
nsOnStartRequestEvent::HandleEvent()
nsStreamListenerEvent::HandlePLEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
_md_EventReceiverProc()
USER32! 77e71820()
00aac1b0()

Comment 5

[Phil Schwartau]

Attachment: Detailed WinNT stack trace + some local values

Comment 6

[Phil Schwartau]

Stack trace indicates this is not JS Engine. 


Upon leaving the page, js_GC is called, which destroys a CSS object, 
which in turn destroys a PresShell object. The destructor of the PresShell 
needs to access its ViewManager. It defends by checking that the pointer 
to the ViewManager is non-0, and it is. However, the ViewManager has in 
reality been destroyed, so mViewManager->DisableRefresh() crashes.


Not sure who is responsible for the relationship between PressShell
and the ViewManager; my best guess is Layout for further analysis.

Comment 7

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

This looks relatively simple to fix.  I think ~nsDocumentViewerImpl just needs
to somehow tell mPresShell to set its view manager to null.  The question is
whether we need to add to nsIPresShell or use some other trick...

Assigning to buster.

Comment 8

[buster]

crashes are P1

Comment 9

[buster]

assigning to kevin.  he knows more about the relative lifetime of these objects
than I do.

david's suggestion by itself isn't the right thing to do.  the view manager
either must live longer than the pres shell, or the frame tree has to be told
that all views referenced by a frame (via frame property) our invalid.  I don't
think this is practical.  We should see why the view manager in this case is
being destroyed before the pres shell, and try to fix that.

Comment 10

[Kevin McCluskey (gone)]

I can't reproduce this problem with the current build. This may have been fixed
by an EventQueue::RevokeEvents patch that was recently checked in.

Marking WORKSFORME.

Comment 11

[Chris Casciano]

I am still having crash problems, although curiously I don't notice the 
talkback dialog appearing anymore. This bug SHOULD NOT be marked resolved.

Win 98/ Build ID: 2001012404

---

MOZILLA executed an invalid instruction in
module <unknown> at 0000:01f9c50d.
Registers:
EAX=0290b990 CS=0167 EIP=01f9c50d EFLGS=00010212
EBX=0290b480 SS=016f ESP=0068f5b8 EBP=0068f5c8
ECX=01f95468 DS=016f ESI=00748fd0 FS=5bef
EDX=00748fd0 ES=016f EDI=00000000 GS=0000
Bytes at CS:EIP:
c5 f9 01 08 c5 f9 01 10 c5 f9 01 10 c5 f9 01 18 
Stack dump:
6020d09a 0290b990 00000000 00748fd0 0068f5f4 602cd0bc 0290b990 02924050 
0290aee0 60215a0b 00748fd0 02924050 00000000 0290aee0 02924050 0068f624 

Comment 12

[buster]

nevermind, I see you did include the build id.  sorry!