Browser crashes on leaving a page running JavaScript

RESOLVED WORKSFORME

Status

()

P1
critical
RESOLVED WORKSFORME
18 years ago
18 years ago

People

(Reporter: chris, Assigned: kmcclusk)

Tracking

({crash})

Trunk
mozilla1.0
x86
All
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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/
(Reporter)

Comment 1

18 years ago
to add... this has been happening with all recent nighlies I've tried, incuding 
the one available this morning... 2001-01-07
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
Assignee: asa → clayton
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
OS: Windows 98 → All
QA Contact: doronr → petersen

Comment 3

18 years ago
Changing component
Assignee: clayton → rogerl
Component: Layout → Javascript Engine
QA Contact: petersen → pschwartau

Comment 4

18 years ago
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()
Summary: Browser crashes on leaving a page running javascript → Browser crashes on leaving a page running JavaScript

Comment 5

18 years ago
Created attachment 22123 [details]
Detailed WinNT stack trace  +  some local values

Comment 6

18 years ago
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.
Assignee: rogerl → clayton
Component: Javascript Engine → Layout
QA Contact: pschwartau → petersen
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.
Assignee: clayton → buster
Severity: normal → critical
Keywords: mozilla0.8

Comment 8

18 years ago
crashes are P1
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.0

Comment 9

18 years ago
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.
Assignee: buster → kmcclusk
Status: ASSIGNED → NEW
(Assignee)

Comment 10

18 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 11

18 years ago
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

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

Updated

18 years ago
Keywords: mozilla0.8
You need to log in before you can comment on or make changes to this bug.