Closed Bug 53953 Opened 24 years ago Closed 24 years ago

crash if i close the "view source" window

Categories

(SeaMonkey :: UI Design, defect, P2)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: tobias.weibel, Assigned: danm.moz)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [rtm++])

Attachments

(2 files)

this is a stack-trace made with ms visual-c++. i hope this is enough.
14.49 KB, text/plain
Details
simple testcase with instructions to reproduce the close view source crasher
716 bytes, text/html
Details 
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
Keywords: crash
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.
Assignee: asa → don
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
QA Contact: doronr → sairuh
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".
Assignee: don → law
Keywords: rtm
Whiteboard: [rtm+]NEED INFO
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...
Status: NEW → ASSIGNED
Whiteboard: [rtm+]NEED INFO → [rtm+]
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.
Assignee: law → rogerl
Status: ASSIGNED → NEW
Component: XP Apps → Javascript Engine
QA Contact: sairuh → pschwartau
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
Assignee: rogerl → danm
I see it with my debug build 20001001 under Win98.

Fix component.
Component: Javascript Engine → XP Apps: GUI Features
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.
Whiteboard: [rtm+] → [rtm-]
i can get this happen using optimized commercial branch bits. i just cannot get
a decent talkback stack trace [yet, still trying]. clearing whiteboard.
Whiteboard: [rtm-]
Setting default QA contact -
QA Contact: pschwartau → sairuh
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.
OS: Windows 2000 → All
Hardware: PC → 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?
Status: NEW → ASSIGNED
Depends on: 52859
Whiteboard: [rtm need info]
Target Milestone: --- → M19
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.
Whiteboard: [rtm need info] → [rtm-]
Target Milestone: M19 → Future
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.
Keywords: helpwanted
Priority: P3 → P2
Whiteboard: [rtm-] → [rtm+ need info]
Target Milestone: Future → M19
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.
Whiteboard: [rtm+ need info] → [rtm+]
r=brendan@mozilla.org, but I'm cc'ing alecf so he can behold in horror, too.

/be
Whiteboard: [rtm+] → [rtm+] yawn
rtm++
Whiteboard: [rtm+] yawn → [rtm++] yawn
patch checked in to trunk and netscape rtm branch
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: [rtm++] yawn → [rtm++]
*** 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.
Keywords: helpwanted → vtrunk
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
Status: RESOLVED → VERIFIED
Keywords: vtrunk
*** 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.
Keywords: mostfreq
*** 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
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
*** 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 :-]
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
I haven't seen this in a while either (NT & Linux), verifying.
Status: RESOLVED → VERIFIED
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: