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
Assignee: clayton → rogerl
QA Contact: petersen → pschwartau
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()
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
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
crashes are P1
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.0
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
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
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
nevermind, I see you did include the build id. sorry!
You need to log in before you can comment on or make changes to this bug.