From Bugzilla Helper: User-Agent: Mozilla/4.75 [en] (Windows NT 5.0; U) BuildID: 2000091312 (pull at ~20:00PDT - 2000/09/24) crash if i close the "view source" window Reproducible: Always Steps to Reproduce: 1. open a homepage 2. "right-click" on the homepage --> view page source 3. close the "view source" window 4. crash

crash keyword

unable to reproduce on winNT with 092505 mozilla trunk build. Tobias can you test this with teh Talkback build and report back with the incident ID of of the talkback report or the email address you used to file the talkback report. I should be able to retrieve a stack trace from that report which may help us narrow this down some. Thanks

adding brendan. stack trace points to a line you last touched. Any ideas? over to XP Apps.

how did you close the source window? if it was by a shortcut, ie, Ctrl+W, then this is prolly bug 53838...

Possible dup of bug 53094 -- someone with a debugger who can reproduce this, look at the JSContext *cx parameter to the top three frames, see if it points at freed memory (on NT, 0xdddddddd filled, I believe). /be

i closed the window by clicking on the cross on the upper right corner.

jrgm, can you repro this on w2k? cannot repro using 2000.09.26.08 branch comm bits on winnt.

I do not get this crash with the branch opt. commercial bits. However, I checked with a debug build pulled 9/26 ~2am, and I do hit this crash. I looked at JSContext *cx, and it is not pointing to freed memory, and appears to be a bona-fide JSContext (or at least VC++ debugger decodes it as such).

In a debug build for the trunk, pulled ~7pm, I can also reproduce this crash closing the view source window (by clicking on the close control (X)). However, this does not happen in a mozilla trunk build 2000092711 win2k (not sure why this appears to be debug only). Note that the crash is preceded by this assertion (which doesn't look like it bodes well) ###!!! ASSERTION: NS_ENSURE_TRUE(docShellAsItem) failed: 'docShellAsItem', file d:\mozilla\mozilla\dom\src\base\nsGlobalWindow.cpp, line 4053 The the stack at the point of that assertion looks like: nsDebug::Assertion(const char * 0x0119f324, const char * 0x0119f314, const char * 0x0119f2e0, int 4053) line 256 + 13 bytes nsDebug::WarnIfFalse(const char * 0x0119f324, const char * 0x0119f314, const char * 0x0119f2e0, int 4053) line 358 + 21 bytes GlobalWindowImpl::GetTreeOwner(GlobalWindowImpl * const 0x03ad2a40, nsIDocShellTreeOwner * * 0x0012ef3c) line 4053 + 38 bytes GlobalWindowImpl::Get_content(GlobalWindowImpl * const 0x03ad2a44, nsIDOMWindowInternal * * 0x0012ef5c) line 701 + 40 bytes nsBrowserInstance::ReinitializeContentVariables() line 475 + 42 bytes nsBrowserInstance::GetContentAreaDocShell(nsIDocShell * * 0x0012eff8) line 497 nsBrowserInstance::Close(nsBrowserInstance * const 0x03c1bba0) line 1496 + 32 bytes nsBrowserInstance::~nsBrowserInstance() line 460 nsBrowserInstance::`scalar deleting destructor'() + 15 bytes nsBrowserInstance::Release(nsBrowserInstance * const 0x03c1bba0) line 563 + 158 bytes nsXPCWrappedNative::~nsXPCWrappedNative() line 398 + 27 bytes nsXPCWrappedNative::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsXPCWrappedNative::Release(nsXPCWrappedNative * const 0x03c1bc38) line 71 + 31 bytes nsXPCWrappedNative::JSObjectFinalized(JSContext * 0x03aa6448, JSObject * 0x03c323e0) line 96 WrappedNative_Finalize(JSContext * 0x03aa6448, JSObject * 0x03c323e0) line 783 js_FinalizeObject(JSContext * 0x03aa6448, JSObject * 0x03c323e0) line 1600 + 114 bytes gc_finalize_phase(JSContext * 0x03aa6448, unsigned int 113) line 907 + 11 bytes js_GC(JSContext * 0x03aa6448, unsigned int 0) line 1173 + 13 bytes js_ForceGC(JSContext * 0x03aa6448) line 871 + 11 bytes js_DestroyContext(JSContext * 0x03aa6448, int 2) line 219 + 9 bytes JS_DestroyContext(JSContext * 0x03aa6448) line 832 + 11 bytes nsJSContext::~nsJSContext() line 366 + 13 bytes nsJSContext::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsJSContext::Release(nsJSContext * const 0x03ad2b58) line 374 + 154 bytes nsCOMPtr<nsIScriptContext>::assign_assuming_AddRef(nsIScriptContext * 0x00000000) line 472 nsCOMPtr<nsIScriptContext>::assign_with_AddRef(nsISupports * 0x00000000) line 849 nsCOMPtr<nsIScriptContext>::operator=(nsIScriptContext * 0x00000000) line 584 nsDocShell::Destroy(nsDocShell * const 0x03ad24d4) line 1614 nsWebShell::Destroy(nsWebShell * const 0x03ad24d4) line 1394 nsXULWindow::Destroy(nsXULWindow * const 0x03a679c4) line 324 nsWebShellWindow::Destroy(nsWebShellWindow * const 0x03a679c4) line 1779 nsWebShellWindow::Close(nsWebShellWindow * const 0x03a67a20) line 368 nsWebShellWindow::HandleEvent(nsGUIEvent * 0x0012f51c) line 447 nsWindow::DispatchEvent(nsWindow * const 0x035fb374, nsGUIEvent * 0x0012f51c, nsEventStatus & nsEventStatus_eIgnore) line 681 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f51c) line 702 nsWindow::DispatchStandardEvent(unsigned int 101) line 722 + 15 bytes nsWindow::ProcessMessage(unsigned int 16, unsigned int 0, long 0, long * 0x0012f854) line 2795 nsWindow::WindowProc(HWND__ * 0x005506dc, unsigned int 16, unsigned int 0, long 0) line 950 + 27 bytes

Bill, can you reproduce this? If not, please mark it "WORKSFORME".

Yes, I reproduced it with the branch commercial build from yesterday. I had to try a couple of times. I found clicking the close box quickly (on the view-source window) seemed to do the trick. Worse, I now can't restart Seamonkey (crashes on startup). Oh, and I can't query my Talkback reports to see what's going on. When it rains, it pours...

It looks like a JS thing. Perhaps related to bug 53123 (which went in real recently). I'll try updating my debug build and see if it works (crashes) differently. Sending to Javascript Engine.

Just to note, I have not been able to reproduce this in an optimized branch build, including 09-29-MN6. However, it is 100% reproducible for me in a debug build on win2k, pulled ~2am 09-29.

*** Bug 54752 has been marked as a duplicate of this bug. ***

This is not bug 53123 or 53123-reopen (that bug was reopened to report a different symptom from the original, and from this one). It's more likely to be related to bug 53094, although that bug seems not to be in talkbacks after the 19th. Another possibility: bug 54380. Reassigning to danm, he loves when I do that! /be

I see it with my debug build 20001001 under Win98.

Fix component.

Note that the crash on a JS_ASSERT from js_AllocGCThing which happens in debug builds is filed as bug 54792. That is the debug code shooting itself in the foot. This bug should be about what can be reproduced in optimized builds, or reproducible if you very quickly close the View Source window after opening it (e.g., do Ctrl-U then Ctrl-W as soon as the page has loaded). That crash will produce a stack similar to the stack at the assertion above in GlobalWindowImpl::GetTreeOwner.

hokay, after doing a very fast ctrl+u, then ctrl+w, i do get a crash (using 2000.09.29.09-n6). got an empty stack trace, but that might be due to the mis-installation of talkback, i think. (will get another, better build.)

*** Bug 54974 has been marked as a duplicate of this bug. ***

PDT marking rtm- unless/until it can be reproduced in the optimized-mode branch build.

i can get this happen using optimized commercial branch bits. i just cannot get a decent talkback stack trace [yet, still trying]. clearing whiteboard.

Setting default QA contact -

No need to get a talkback trace. It is clear where the crash in the optimized build is occuring. And yes, it is reproducible in the opt. builds, but only on a relatively narrow timing window.

I managed to crash like this by doing a fast Command-U command-W: Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 1F4A8B5C 0B41A540 PPC 1F493498 main+00130 0B41A4E0 PPC 1F4929AC main1(int, char**, nsISupports*)+0083C 0B41A230 PPC 1F362100 nsAppShellService::Run()+00018 0B41A1F0 PPC 1CDF8EB4 nsAppShell::Run()+00048 0B41A1A0 PPC 1CDF95F0 nsMacMessagePump::DoMessagePump()+0003C 0B41A150 PPC 1CDF9C04 nsMacMessagePump::DispatchEvent(int, EventRecord*)+ 00170 0B41A100 PPC 1CE1161C Repeater::DoRepeaters(const EventRecord&)+00030 0B41A0C0 PPC 1CDD7544 nsMacNSPREventQueueHandler::RepeatAction(const EventRecord&)+000 0C 0B41A080 PPC 1CDD765C nsMacNSPREventQueueHandler::ProcessPLEventQueue()+ 000B0 0B41A010 PPC 1D2D7918 nsEventQueueImpl::ProcessPendingEvents()+00038 0B419FA0 PPC 1D338FB0 PL_ProcessPendingEvents+0005C 0B419F60 PPC 1D339134 PL_HandleEvent+00020 0B419F20 PPC 1D3127F4 EventHandler(PLEvent*)+00048 0B419ED0 PPC 1D30C1FC XPTC_InvokeByIndex+0000C 0B419E90 PPC 1D30C304 _XPTC_InvokeByIndex+000C8 0B419DDC PPC 1DA4F7A4 OnStatus__15nsDocLoaderImplFP10nsIChannelP11nsISupportsUiPCw+001 44 0B419D4C PPC 1DA4FD88 FireOnStatusChange__15nsDocLoaderImplFP14nsIWebProgressP10nsIReq uestUiPCw+00078 PowerPC illegal instruction at 0BF40000 Disassembling PowerPC code from 0BF3FFD8 No procedure name 0BF3FFD8 dc.l 0x00000000 | 00000000 0BF3FFDC dc.l 0x00000018 | 00000018 0BF3FFE0 dc.l 0x0000019C | 0000019C 0BF3FFE4 dc.l 0x0BF3FF8C | 0BF3FF8C 0BF3FFE8 dc.l 0x0BD3D2F0 | 0BD3D2F0 0BF3FFEC andi. SP,r19,0x6D65 | 72616D65 0BF3FFF0 bdz+ $+0x7264 ; 0x0BF47254 | 426F7264 0BF3FFF4 oris r18,r11,0x735F | 6572735F 0BF3FFF8 rlwnm r17,r25,r6,0x1D,0x17 | 5F31376E 0BF3FFFC andi. r9,r26,0x4C61 | 73494C61 0BF40000 *dc.l 0x796F7574 | 796F7574 0BF40004 svcl 0x189D | 44656275 0BF40008 oris r7,r27,0x6572 | 67676572 0BF4000C dc.l 0x00000030 | 00000030 0BF40010 dc.l 0x0000016C | 0000016C 0BF40014 dc.l 0x0BF3FFE4 | 0BF3FFE4 0BF40018 dc.l 0x00550BF3 | 00550BF3 0BF4001C fcmpu cr7,fp12,fp0 | FFCC0000 0BF40020 dc.l 0x00000000 | 00000000 0BF40024 dc.l 0x00000018 | 00000018 Closing log

thx, jrgm. just recently repro'd this using linux opt comm branch bits --since simon saw this on mac, gonna mark this all.

This bug will be magically fixed when bug 52859 is fixed. But the ETA on that one is currently post ship, so ... I guess it wants a solution all its own. Accepting for rtm. I wonder if I'm allowed to do that by myself?

I have the same stack trace & crash when I close view source OR the AIM message window. No fast moves required, wait all you want and still 100% crash. See bug 54257.

Heikki, this bug's true stack ends with an assertbotch in GlobalWindowImpl::GetTreeOwner called a few frames down from nsBrowserInstance::ReinitializeContentVariables. There was a false report here of a JS crash, but it's due to the fact that nsDebug::Assertion nests an event loop (using MessageBox on Windows) that runs all events, leading to unsafe and non-reentrant control flows. If you are seeing a crash in js_AllocGCThing at line 381 of jsgc.c, but no underlying nsBrowserInstance::ReinitializeContentVariables leading to a nested event loop from nsDebug::Assertion, then you are not seeing this bug. /be

rtm-/future, fixing an obscure crash is not going to help our MTBF, nominate for dogfood if this is making product unusable in debug builds.

This happened to me last night in an optimized Mozilla build (2000100208) Win32. I was not able to duplicate it. Talkback never caught the crash.

Ok. I have a file that can reproduce it 100% of the time in my optimized talkback build. There are no symbols, but here's what MSVC++ says about it (Talkback does not catch this one). Will attach file after confirm on latest build. 00000000() JSDOM! 60b159e4() MOZBRWSR! 604d14c2() MOZBRWSR! 604d157c() MOZBRWSR! 604d3759() MOZBRWSR! 604d13e5() MOZBRWSR! 604d1397() JS3250! 60ae014d() JS3250! 60ad5313() JS3250! 60ad5147() JS3250! 60ad4bd1() JS3250! 60ac1ca7() JSDOM! 60b1e6e3() DOCSHELL! 601135ce() APPSHELL! 60087b76() GKWIDGET! 60a75ce0() GKWIDGET! 60a75d7b() GKWIDGET! 60a775f9() GKWIDGET! 60a76140() USER32! 77e148dc() USER32! 77e163fb() USER32! 77e1643d() NTDLL! 77f9f04b() USER32! 77e15b59() USER32! 77e148dc() USER32! 77e17ef9() USER32! 77e17f75() GKWIDGET! 60a76161() USER32! 77e148dc() USER32! 77e163fb() USER32! 77e1643d() NTDLL! 77f9f04b() USER32! 77e15b59() USER32! 77e148dc() USER32! 77e17ef9() USER32! 77e17f75() GKWIDGET! 60a76161() USER32! 77e148dc() USER32! 77e14aa7() USER32! 77e266fd() APPSHELL! 60085dde() MOZILLA! 00401230() MOZILLA! 00402aae() KERNEL32! 77e992a6()

Ok. It does not need my file to do it, but it is 100% reproducible if you open a local HTML file, right-click -> view source, then click on the X to close view source.

*** Bug 55338 has been marked as a duplicate of this bug. ***

Several Talkback reports filed. Try these: TB18595185H TB18595127M TB18595038K

jerry, your talkback reports are also empty of symbols (as are mine). I can also reproduce this by opening the browser and viewing source on the blank page that it incorrectly starts with and then closing that.

This happens occasionally on real sites, but it is reproducible 100% on local files. This is not with a debug build. Why is this rtm-?

Because we didn't have that information during triage! marking rtm+ need info, and adding helpwanted keyword since Dan is overloaded and may not get to it. (Can't mark rtm+ until we attach a patch and get r=/a=) cc self.

The test case I just added, after following its instructions, crashed Mozilla every time I tried it in build 2000100504 M18 on win32. Note: you do need to follow the instructions listed in the testcase to reproduce this. Jake

Thanks! that should help.

I am not crashing all the time with optimized build & view source, but occasionally. I have an optimized branch build with debug symbols. I seem to be getting different stack traces. Here is one: 0217298b() nsBrowserInstance::GetContentAreaDocShell(nsBrowserInstance * const 0x02172938, nsIDocShell * * 0x0012f678) line 497 nsBrowserInstance::Close(nsBrowserInstance * const 0x00000000) line 1497 nsBrowserInstance::~nsBrowserInstance(nsBrowserInstance * const 0x02172938) line 460 nsBrowserInstance::`scalar deleting destructor'() + 8 bytes nsBrowserInstance::Release(nsBrowserInstance * const 0x02dd4890) line 563 + 32 bytes nsXPCWrappedNative::~nsXPCWrappedNative(nsXPCWrappedNative * const 0x02172938) line 398 + 13 bytes nsXPCWrappedNative::Release(nsXPCWrappedNative * const 0x02dd4850) line 72 nsXPCWrappedNative::JSObjectFinalized(nsXPCWrappedNative * const 0x02172938, JSContext * 0x03a3ea10, JSObject * 0x02134e20) line 95 + 12 bytes WrappedNative_Finalize(JSContext * 0x03a3ea10, JSObject * 0x02134e20) line 783 js_FinalizeObject(JSContext * 0x03a3ea10, JSObject * 0x02dd4810) line 1603 gc_finalize_phase(JSContext * 0x03a3ea10, unsigned int 0x00c443a0) line 907 + 10 bytes js_GC(JSContext * 0x03a3ea10, unsigned int 0x00000000) line 1173 + 11 bytes js_ForceGC(JSContext * 0x03a3ea10) line 871 + 12 bytes js_DestroyContext(JSContext * 0x00000000, int 0x00000002) line 220 JS_DestroyContext(JSContext * 0x03a3ea10) line 831 + 11 bytes nsJSContext::~nsJSContext(nsJSContext * const 0x02172938) line 366 + 9 bytes nsJSContext::`scalar deleting destructor'(nsJSContext * const 0x02172938, unsigned int 0x00000001) + 8 bytes nsJSContext::Release(nsJSContext * const 0x03a3a030) line 374 + 28 bytes nsCOMPtr_base::assign_with_AddRef(nsCOMPtr_base * const 0x02172938, nsISupports * 0x00000000) line 59 nsWebShell::Destroy(nsWebShell * const 0x03a3a484) line 1393 nsXULWindow::Destroy(nsXULWindow * const 0x00000000) line 325 nsWebShell::Destroy(nsWebShell * const 0x03a3a484) line 1393 nsXULWindow::Destroy(nsXULWindow * const 0x03a3a484) line 325 nsWebShellWindow::Destroy(nsWebShellWindow * const 0x03a39a84) line 1779 nsWebShellWindow::Close(nsWebShellWindow * const 0x03a39adc) line 368 nsWebShellWindow::HandleEvent(nsGUIEvent * 0x03a39a80) line 457 nsWindow::DispatchEvent(nsWindow * const 0x03a398e4, nsGUIEvent * 0x0012f938, nsEventStatus & nsEventStatus_eIgnore) line 681 + 6 bytes nsWindow::DispatchWindowEvent(nsWindow * const 0x02172938, nsGUIEvent * 0x00000000) line 702 nsWindow::DispatchStandardEvent(nsWindow * const 0x02172938, unsigned int 0x00000065) line 722 + 11 bytes nsWindow::ProcessMessage(nsWindow * const 0x02172938, unsigned int 0x00000010, unsigned int 0x00000000, long 0x00000000, long * 0x0012fadc) line 2796 nsWindow::WindowProc(HWND__ * 0x033f01bc, unsigned int 0x00000010, unsigned int 0x00000000, long 0x00000000) line 950 + 18 bytes USER32! 77e719d0() USER32! 77e71982() NTDLL! 77f763a3() USER32! 77e718d2() nsWindow::DefaultWindowProc(HWND__ * 0x033f01bc, unsigned int 0x00000112, unsigned int 0x0000f060, long 0x001603e0) line 977 USER32! 77e727fe() USER32! 77e72889() nsWindow::WindowProc(HWND__ * 0x033f01bc, unsigned int 0x00000112, unsigned int 0x0000f060, long 0x00000000) line 957 + 23 bytes USER32! 77e719d0() USER32! 77e71982() NTDLL! 77f763a3() USER32! 77e718d2() nsWindow::DefaultWindowProc(HWND__ * 0x033f01bc, unsigned int 0x000000a1, unsigned int 0x00000014, long 0x001603e0) line 977 USER32! 77e727fe() USER32! 77e72889() nsWindow::WindowProc(HWND__ * 0x033f01bc, unsigned int 0x000000a1, unsigned int 0x00000014, long 0x00000000) line 957 + 23 bytes USER32! 77e71820() 001603e0()

Here is another stack trace, closed view source window with Ctrl+w. 020c38c5() nsBrowserInstance::GetContentAreaDocShell(nsBrowserInstance * const 0x020c3870, nsIDocShell * * 0x0012f6a0) line 497 nsBrowserInstance::Close(nsBrowserInstance * const 0x00000000) line 1497 nsBrowserInstance::~nsBrowserInstance(nsBrowserInstance * const 0x020c3870) line 460 nsBrowserInstance::`scalar deleting destructor'() + 8 bytes nsBrowserInstance::Release(nsBrowserInstance * const 0x036ba140) line 563 + 32 bytes nsXPCWrappedNative::~nsXPCWrappedNative(nsXPCWrappedNative * const 0x020c3870) line 398 + 13 bytes nsXPCWrappedNative::Release(nsXPCWrappedNative * const 0x036ba100) line 72 nsXPCWrappedNative::JSObjectFinalized(nsXPCWrappedNative * const 0x020c3870, JSContext * 0x03227690, JSObject * 0x02031960) line 95 + 12 bytes WrappedNative_Finalize(JSContext * 0x03227690, JSObject * 0x02031960) line 783 js_FinalizeObject(JSContext * 0x03227690, JSObject * 0x036ba0c0) line 1603 gc_finalize_phase(JSContext * 0x03227690, unsigned int 0x00c44440) line 907 + 10 bytes js_GC(JSContext * 0x03227690, unsigned int 0x00000000) line 1173 + 11 bytes js_ForceGC(JSContext * 0x03227690) line 871 + 12 bytes js_DestroyContext(JSContext * 0x00000000, int 0x00000002) line 220 JS_DestroyContext(JSContext * 0x03227690) line 831 + 11 bytes nsJSContext::~nsJSContext(nsJSContext * const 0x020c3870) line 366 + 9 bytes nsJSContext::`scalar deleting destructor'(nsJSContext * const 0x020c3870, unsigned int 0x00000001) + 8 bytes nsJSContext::Release(nsJSContext * const 0x03221f90) line 374 + 28 bytes nsCOMPtr_base::~nsCOMPtr_base(nsCOMPtr_base * const 0x020c3870) line 50 GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x03227240, nsIPresContext * 0x036c4640, nsEvent * 0x0012fba4, nsIDOMEvent * * 0x0012f958, unsigned int 0x00000002, nsEventStatus * 0x0012fb6c) line 541 + 8 bytes nsDocument::HandleDOMEvent(nsDocument * const 0x036c4ca0, nsIPresContext * 0x036c4640, nsEvent * 0x0012fba4, nsIDOMEvent * * 0x0012f958, unsigned int 0x00000002, nsEventStatus * 0x0012fb6c) line 3051 + 18 bytes nsGenericElement::HandleDOMEvent(nsGenericElement * const 0x020c3870, nsIPresContext * 0x036c4640, nsEvent * 0x00000000, nsIDOMEvent * * 0x0012f958, unsigned int 0x00000001, nsEventStatus * 0x0012fb6c) line 1433 + 21 bytes nsHTMLSpanElement::HandleDOMEvent(nsHTMLSpanElement * const 0x036c6a28, nsIPresContext * 0x036c4640, nsEvent * 0x0012fba4, nsIDOMEvent * * 0x00000000, unsigned int 0x00000001, nsEventStatus * 0x0012fb6c) line 172 PresShell::HandleEventInternal(PresShell * const 0x020c3870, nsEvent * 0x0012fba4, nsIView * 0x036bd0a0, unsigned int 0x00000001, nsEventStatus * 0x0012fb6c) line 4255 + 21 bytes PresShell::HandleEvent(PresShell * const 0x036aed90, nsIView * 0x036bd0a0, nsGUIEvent * 0x0012fba4, nsEventStatus * 0x0012fb6c, int 0x00000000, int & 0x00000001) line 4190 + 17 bytes nsView::HandleEvent(nsView * const 0x00000000, nsGUIEvent * 0x0012fba4, unsigned int 0x00000008, nsEventStatus * 0x0012fb6c, int 0x00000000, int & 0x00000001) line 379 nsView::HandleEvent(nsView * const 0x00000000, nsGUIEvent * 0x036bd0a0, unsigned int 0x00000008, nsEventStatus * 0x0012fb6c, int 0x00000000, int & 0x00000001) line 352 nsView::HandleEvent(nsView * const 0x00000000, nsGUIEvent * 0x036bb020, unsigned int 0x0000001c, nsEventStatus * 0x0012fb6c, int 0x00000001, int & 0x00000001) line 352 nsViewManager2::DispatchEvent(nsViewManager2 * const 0x00000000, nsGUIEvent * 0x00000000, nsEventStatus * 0x0012fb6c) line 1439 HandleEvent(nsGUIEvent * 0x036ab420) line 68 nsWindow::DispatchEvent(nsWindow * const 0x036aa334, nsGUIEvent * 0x0012fba4, nsEventStatus & nsEventStatus_eIgnore) line 681 + 6 bytes nsWindow::DispatchWindowEvent(nsWindow * const 0x020c3870, nsGUIEvent * 0x00000000) line 702 nsWindow::DispatchKeyEvent(nsWindow * const 0x020c3870, unsigned int 0x00000083, unsigned short 0x0077, unsigned int 0x00000000) line 2284 + 18 bytes nsWindow::OnChar(nsWindow * const 0x020c3870, unsigned int 0x00170017, unsigned int 0x00000077, unsigned char 0x00) line 2405 + 16 bytes nsWindow::ProcessMessage(nsWindow * const 0x020c3870, unsigned int 0x00000102, unsigned int 0x00000017, long 0x00110001, long * 0x0012fd8c) line 2836 nsWindow::WindowProc(HWND__ * 0x01f301ce, unsigned int 0x00000102, unsigned int 0x00000017, long 0x00000000) line 950 + 18 bytes USE

*** Bug 55542 has been marked as a duplicate of this bug. ***

patch to fix: --- ./xpfe/browser/src/nsBrowserInstance.cpp-1.166 Fri Oct 6 15:32:11 2000 +++ ./xpfe/browser/src/nsBrowserInstance.cpp Fri Oct 6 15:30:27 2000 @@ -480,18 +480,18 @@ nsresult nsBrowserInstance::GetContentAreaDocShell(nsIDocShell** outDocShell) { nsCOMPtr<nsIDocShell> docShell(do_QueryReferent(mContentAreaDocShellWeak)); - if (docShell) { - // the docshell still exists, but has it been destroyed? + if (!mIsClosed && docShell) { + // we're still alive and the docshell still exists. but has it been destroyed? nsCOMPtr<nsIBaseWindow> hack = do_QueryInterface(docShell); if (hack) { nsCOMPtr<nsIWidget> parent; hack->GetParentWidget(getter_AddRefs(parent)); if (!parent) // it's a zombie. a new one is in place. set up to use it. docShell = 0; } } - if (!docShell) + if (!mIsClosed && !docShell) ReinitializeContentVariables(); docShell = do_QueryReferent(mContentAreaDocShellWeak);

a=hyatt.

r=brendan@mozilla.org, but I'm cc'ing alecf so he can behold in horror, too. /be

rtm++

patch checked in to trunk and netscape rtm branch

*** Bug 55647 has been marked as a duplicate of this bug. ***

*** Bug 55834 has been marked as a duplicate of this bug. ***

no longer crashes when using the attached testcase. needs to be verified with trunks bits --but this is vrfy fixed using 2000.10.09.xx-n6 [opt comm] branch bits on winnt, linux and mac.

not happening in trunk win98 2000101704

Verified Fixed on trunk builds Testcase does not crash. linux 101808 RedHat 6.2 win32 101804 NT 4 mac 101804 Mac OS9 Setting bug to Verified and removing vtrunk keyword

*** Bug 56717 has been marked as a duplicate of this bug. ***

*** Bug 58113 has been marked as a duplicate of this bug. ***

*** Bug 58211 has been marked as a duplicate of this bug. ***

Most Freq we're still getting reports of this.

*** Bug 57272 has been marked as a duplicate of this bug. ***

reopening. we're stil getting reports of this. I cannot reproduce with mozilla trunk win32 builds on NT

*** Bug 58511 has been marked as a duplicate of this bug. ***

The recent duplicates have build ID of -- two are 10/10, one is 09/13 and two are M18 (branched 10/12 from MN6?). I can't reproduce this in the today's trunk or branch builds on win2k, or current branch on mac and linux. Since this bug is rtm++, there is no evidence that this is happening on current builds, I'm re-resolving as FIXED. Open a new bug to track three week old crashers that no one can reproduce if you would like :-]

I haven't seen this in a while either (NT & Linux), verifying.

Mass removing self from CC list.

Now I feel sumb because I have to add back. Sorry for the spam.