Closed Bug 39858 Opened 24 years ago Closed 24 years ago

On linux messenger crashes when do a File|Quit

Categories

(MailNews Core :: Backend, defect, P3)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 43472

People

(Reporter: fenella, Assigned: jband_mozilla)

References

Details

(Keywords: crash, smoketest, topcrash, Whiteboard: [dogfood+][nsbeta2+])

Attachments

(1 file)

proposed fix
4.44 KB, patch
Details | Diff | Splinter Review 
Linux (2000-05-19-08 M16)
1. Launch messenger using the -mail 
@. Enter password (imap account)
2. Do a File|Quit

Actual result: Crash

Expected result: should not crash

This occurs in IMAP account. Does not occur in Browser. Does not occur when
click on the window (X) close widget.

Have not test Mac and Win32 yet.
Keywords: nsbeta2, smoketest
I meant the talkback dialog comes up when do a File|Quit. Is it considered a
crash??
Summary: [PP]Linux messenger crashes when File|Quit in IMAP → [PP]Linux messenger:talkback dialog comes up when do a File|Quit
Summary: [PP]Linux messenger:talkback dialog comes up when do a File|Quit → [PP]Linux messenger crashes when do a File|Quit
Priority: P3 → P1
So it doesn't crash, you just see a talkback thing come up? Can you try
submitting the report and we can see if there is a stack trace associated with
the talback?
Priority: P1 → P3
Win32 (2000-05-19-09 M16)
The crash occurs on win32 win_nt/ 
NSPR:EventReceiver:Netscape 6 - Application error
Mac (2000-05-19-08 M16)
I do not see any crash on Mac
On Linux, I tried two more scenarios:
1. Removed all the summary (summary) files, it crashes
2. Ran with a new profile, it crashes consistently in IMAP
Scott, I am unable to access the Talkbalk stack trace. It hangs forever.Sorry.
OK, I crashed too on all platforms when I Launched Mail, Selected my IMAP 
account and gave password, did not open a message, just did a File|Quit(Exit).
Note: if you have save password you don't crash.  I haven't specifically tried 
my POP account with this scenario.  I will and update this.

Here is the talkback for linux system:

 Call Stack:    (Signature = libraptorhtml.so + 0x1c000a (0x40b2100a) b00292b7) 
libraptorhtml.so + 0x1c000a (0x40b2100a) 
libraptorhtml.so + 0x1f3839 (0x40b54839) 
libraptorhtml.so + 0x1c6ffa (0x40b27ffa) 
libraptorhtml.so + 0x1c6f8c (0x40b27f8c) 
libraptorhtml.so + 0x1e185d (0x40b4285d) 
libraptorhtml.so + 0x1e14d1 (0x40b424d1) 
libxpcom.so + 0x768af (0x400b78af) 
libraptorhtml.so + 0x390383 (0x40cf1383) 
libraptorhtml.so + 0x38ff45 (0x40cf0f45) 
libxpcom.so + 0x768ff (0x400b78ff) 
libdocshell.so + 0xf130 (0x4093a130) 
libraptorwebwidget.so + 0xfabc (0x40921abc) 
libnsappshell.so + 0x116d8 (0x4037a6d8) 
libnsappshell.so + 0x1a4a0 (0x403834a0) 
libnsappshell.so + 0x16e2b (0x4037fe2b) 
libnsappshell.so + 0x14b14 (0x4037db14) 
libnsappshell.so + 0x14c41 (0x4037dc41) 
libxpconnect.so + 0x2c9b6 (0x403549b6) 
libxpconnect.so + 0x2c2c5 (0x403542c5) 
libxpconnect.so + 0x2c35e (0x4035435e) 
libxpconnect.so + 0x30606 (0x40358606) 
libmozjs.so + 0x373da (0x401163da) 
libmozjs.so + 0x27696 (0x40106696) 
libmozjs.so + 0x270ed (0x401060ed) 
libmozjs.so + 0x14efc (0x400f3efc) 
libmozjs.so + 0xda9e (0x400eca9e) 
libjsloader.so + 0x3a39 (0x41472a39) 
libjsloader.so + 0x3ae9 (0x41472ae9) 
libxpcom.so + 0x4029b (0x4008129b) 
libxpcom.so + 0x3faab (0x40080aab) 
libplds4.so + 0x1410 (0x40155410) 
libxpcom.so + 0x3fe48 (0x40080e48) 
libxpcom.so + 0x402d3 (0x400812d3) 
libxpcom.so + 0x64722 (0x400a5722) 
libxpcom.so + 0x3ba0d (0x4007ca0d) 
mozilla-bin + 0x5717 (0x0804d717) 
libc.so.6 + 0x181eb (0x4023e1eb) 
                                                


Incident # 10822822
Here's the mac talk back:
 Call Stack:    (Signature = .__ptr_glue f695b6ab) 
 .__ptr_glue 
ClusterKeySet::~ClusterKeySet() 
[nsXULTemplateBuilder.cpp, line 1269]
nsXULTemplateBuilder::CreateContainerContents() 
[nsXULTemplateBuilder.cpp, line 5729]
nsXULTemplateBuilder::CreateTemplateAndContainerContents() 
[nsXULTemplateBuilder.cpp, line 5622]
nsXULTemplateBuilder::CreateContents() 
[nsXULTemplateBuilder.cpp, line 4106]
nsXULDocument::CreateContents() 
[nsXULDocument.cpp, line 2114]
nsXULElement::EnsureContentsGenerated() 
[nsXULElement.cpp, line 3858]
nsXULElement::ChildAt() 
[nsXULElement.cpp, line 2569]
nsXULDocument::AddSubtreeToDocument() 
[nsXULDocument.cpp, line 2986]
nsXULDocument::AddSubtreeToDocument() 
[nsXULDocument.cpp, line 2986]
nsXULDocument::AddSubtreeToDocument() 
[nsXULDocument.cpp, line 2986]
nsXULDocument::Merge() 
[nsXULDocument.cpp, line 5862]
nsXULDocument::Resolve() 
[nsXULDocument.cpp, line 5776]
nsXULDocument::ResolveForwardReferences() 
[nsXULDocument.cpp, line 2206]
nsXULDocument::ResumeWalk() 
[nsXULDocument.cpp, line 5133]


Changin to All removing [PP]
OS: Linux → All
Hardware: Other → All
Summary: [PP]Linux messenger crashes when do a File|Quit → All platforms messenger crashes when do a File|Quit
This crashed with my POP account on Win98 too (haven't tried POP on the other 
platforms yet).  Note: if you save password and run through my scenario, you 
don't crash.  If you do a File|Close while in Messenger, then quit Browser you 
don't crash.  
[dogfood+]
Keywords: dogfood
Whiteboard: [dogfood+]
I can reproduce this bug on Mac 2000-05-22-08-M16 comm build on both IMAP and 
POP.
Linux (2000-05-22-08 M16)
Win (2000-05-22-09 M16)
This build can be reproduced in today's builds too.
I see this happening on other apps when you quit also, like Composer and the 
browser.


Mac (2000-05-22-08 M16)
I still do not see any crash on Mac. I tried it many times using Esther's steps.
Here's the stack trace I see from talkback:

CNavDTD::DidBuildModel
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 589]

nsParser::DidBuildModel
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 991]

nsParser::Terminate
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1060]

nsHTMLDocument::StopDocumentLoad
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLDocument.cpp, line 808]

nsDocShell::Stop
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 1085]

nsDocShell::Stop
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 1100]

nsDocShell::Destroy
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 1284]

nsWebShell::Destroy
[d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 1598]

nsXULWindow::Destroy
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsXULWindow.cpp, line 424]

nsWebShellWindow::Destroy
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 1732]

nsWebShellWindow::Close
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 364]

nsWebShellWindow::HandleEvent
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 453]


In handling, the on Quit event, we end up in CNavDTD::DidbuildModel where we crash.

Adding crash keyword
Keywords: crash
This crash happens when quiting any of the apps, not just mailnews. I need to
find the right owner for this.
Target Milestone: --- → M16
I just tried this on Win2K and MacOS with fresh builds and I don't see a 
crash in messenger or anything else.
It would be great if this got fixed. It tends to only manifest itself on release
builds though. I don't know if that's what saari was trying or not.

setting ETA. I'm out this week at mail connect.
Whiteboard: [dogfood+] → [dogfood+] ETA: 6/6
Saari: Can you confirm that you could not reproduce with a non-debug build?
Thanks,
Jim
I saw this crash today quitting aim with browser in background on win32 
2000-05-31-09M16 build (WinNT)
Linux (2000-05-31-08 M16)
Win32 (2000-05-31-09 M16)
Mac (2000-05-31-08 M16)
I do not see this bug on Mac. But I still see it on today's Linux and Win32 
builds.
I can repro on this morning's non-debug commercial win32 build. However, it is a 
very specific set of things that I need to do to reproduce it.

My mail is set up with POP and it will always ask for a password.

1) launch navigator
2) launch messenger from task bar
3) dismiss mail password dialog by clicking Cancel (NOTE: If I enter my password 
here and check mail I do _not_ crash when quitting messenger)
3) click on Get Msg button in toolbar
4) enter password in dialog, click OK
5) quit messenger and crash

The above chicken dance also works on my debug build

Linux (2000-06-01-08 M16)
Win32 (2000-06-01-09 M16)
Mac (2000-06-01-08 M16)
Same result as yesterday. 
I do not see this bug on Mac. But I still see it on today's Linux and Win32 
builds.
Linux (2000-06-02-08 M16)
Win32 (2000-06-02-09 M16)
Mac (2000-06-02-08 M16)
Same result as yesterday. 
I do not see this bug on Mac. But I still see it on today's Linux and Win32 
builds.
Jan, do you want me to update this bug every day?
 After a crash caused by this bug, Linux Aim is unstable in that attempting to 
login after the crash caused us to hang at stage 5 of login ("Starting").
Whiteboard: [dogfood+] ETA: 6/6 → [dogfood+][beta2+] ETA: 6/6
Whiteboard: [dogfood+][beta2+] ETA: 6/6 → [dogfood+][nsbeta2+] ETA: 6/6
Fenella - no need to update this bug every day if no one has worked on the bug

Hi Fenella, there were some changes that got checked in yesterday that could
have effected (and hopefully fixed this bug). Can you try it again?


Unless it's a different crash, I still get crashes on File quit with AIM or 
browser using todays builds. :-(
adding myself to cc list.
Okay I somehow really need to find the right owner for this bug. It has nothing
to do with mail (we can crash when closing the browser or aim or any other
component too). But the crash is always in a random spot and is always changing
(at least for me). Makes it harder to pin down an owner.


cc'ing danm in case he has any ideas.

If it's any help, I usually see it when launching one app(say, browser) then 
spawn another app from that one via switcher or task menu (say Aim or Mail).
If you then File-->Quit the spawned app, you crash.
I was able to reproduce this about 1/3 of the time using esther's password 
dialog steps with a stack trace that was the same as the one in 40775 and then I 
reproduced this consistently with saari's password dialog steps with the 
following stack trace every time. Perhaps we should run Purify on this.

PR_Lock(PRLock * 0xdddddddd) line 228 + 3 bytes
nsAutoLock::nsAutoLock(PRLock * 0xdddddddd) line 135 + 13 bytes
nsXPCWrappedNativeClass::~nsXPCWrappedNativeClass() line 169
nsXPCWrappedNativeClass::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsXPCWrappedNativeClass::Release(nsXPCWrappedNativeClass * const 0x05bef960) 
line 64 + 129 bytes
nsXPCWrappedNative::~nsXPCWrappedNative() line 391 + 27 bytes
nsXPCWrappedNative::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsXPCWrappedNative::Release(nsXPCWrappedNative * const 0x05bee660) line 71 + 31 
bytes
nsXPCWrappedNative::JSObjectFinalized(JSContext * 0x049f5930, JSObject * 
0x02e2aac0) line 96
WrappedNative_Finalize(JSContext * 0x049f5930, JSObject * 0x02e2aac0) line 691
js_FinalizeObject(JSContext * 0x049f5930, JSObject * 0x02e2aac0) line 1483 + 114 
bytes
js_GC(JSContext * 0x049f5930) line 1035 + 11 bytes
js_ForceGC(JSContext * 0x049f5930) line 770 + 9 bytes
js_DestroyContext(JSContext * 0x049f5930, int 0) line 195 + 9 bytes
JS_Finish(JSRuntime * 0x01401d80) line 658 + 11 bytes
nsJSRuntimeServiceImpl::~nsJSRuntimeServiceImpl() line 54 + 13 bytes
nsJSRuntimeServiceImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsJSRuntimeServiceImpl::Release(nsJSRuntimeServiceImpl * const 0x01282290) line 
62 + 129 bytes
nsServiceManager::ReleaseService(const char * 0x005359fc 
kJSRuntimeServiceProgID, nsISupports * 0x01282290, nsIShutdownListener * 
0x00000000) line 607 + 12 bytes
nsJSEnvironment::~nsJSEnvironment() line 1244 + 20 bytes
nsJSEnvironment::`scalar deleting destructor'(unsigned int 1) + 15 bytes
JSEnvironmentInit::~JSEnvironmentInit() line 1179 + 30 bytes
$E5() + 13 bytes
_CRT_INIT(void * 0x00470000, unsigned long 0, void * 0x00000001) line 236
_DllMainCRTStartup(void * 0x00470000, unsigned long 0, void * 0x00000001) line 
289 + 17 bytes
NTDLL! 77f69dca()
KERNEL32! 77f19ffb()
doexit(int 0, int 0, int 0) line 392
exit(int 0) line 279 + 13 bytes
mainCRTStartup() line 345

I get a crash with a stack trace very much like Scott's, above, when I follow 
Chris' Chicken Dance, with some interpretation. (Trace "very much like" meaning 
identical, but replace

PR_Lock(PRLock * 0xdddddddd) line 228 + 3 bytes
nsAutoLock::nsAutoLock(PRLock * 0xdddddddd) line 135 + 13 bytes
nsXPCWrappedNativeClass::~nsXPCWrappedNativeClass() line 169

at the top with

js_RemoveRoot(JSRuntime * 0xdddddddd, void * 0x0420d480) line 183 + 3 bytes
JS_RemoveRootRT(JSRuntime * 0xdddddddd, void * 0x0420d480) line 1080 + 13 bytes
nsXPCWrappedNative::Release(nsXPCWrappedNative * const 0x0420d470) line 78 + 22 
bytes
nsXPCWrappedNative::~nsXPCWrappedNative() line 366 + 18 bytes

Both stacks seem to point at JS objects already partially destroyed when being 
garbage collected. Brendan?

Something's wrotten, not in the JS GC I think, but possibly in the XPConnect 
code.  Cc'ing mccabe, adding waterson.  McCabe, you wanna take this one?

/be
reassigning to mccabe based on Brendan's comments.
Assignee: mscott → mccabe
Removing ETA date since bug was re-assigned.

...but we'll nee a new one RSN.

Thanks,

Jim
Whiteboard: [dogfood+][nsbeta2+] ETA: 6/6 → [dogfood+][nsbeta2+]
There is a certain similarity between putterman's stack trace from 6/6 and
those of bug 41136 "Crash while closing aim after signoff" and bug 41335 "Crash
while closing a browser window" (which actually doesn't crash any more in recent
builds). 
danm's stack trace from 6/7 in js_RemoveRoot reminds me of bug 31695 
"Crash exiting after trigger with callback function", owned by dveditz.
See Comments From dveditz@netscape.com 2000-03-13 19:38 in that bug:
> [...] occasional crash freeing JS GC roots. IF a) the triggering page has a 
> trigger-callback function and b) you exit from the triggering page without 
> loading a new page you will usually crash during exit. This is on my list of 
> things to fix but I hadn't written a bug yet; this one will do.  The problem 
> is shutdown order.
Adding him to cc.
alecf's checkin on 6/6 1:07 to nsGlobalWindow.cpp (see bug 41608 and my 
comments in bug 41335) may have influenced the symptoms of this bug as well.

*** Bug 42256 has been marked as a duplicate of this bug. ***
I've been able to reproduce this, at the same heisenberg frequency, using the
'get mail requiring password' formula.

#2  0x40267674 in PR_Assert (s=0x4029720a "0 == rv", 
    file=0x40297200 "ptsynch.c", ln=168) at prlog.c:477
#3  0x40283aec in PR_Lock (lock=0x81b1ea8) at ptsynch.c:168
#4  0x40146c3e in nsAutoLock::nsAutoLock (this=0xbffff54c, aLock=0x81b1ea8)
    at ../../../../dist/include/nsAutoLock.h:135
#5  0x4069a1f2 in nsXPCWrappedNativeClass::~nsXPCWrappedNativeClass (
    this=0x8dbfa60, __in_chrg=3) at xpcwrappednativeclass.cpp:168

A comment in nsAutoLock.h -
        // This will assert deep in the bowels of NSPR if you attempt
        // to re-enter the lock.
implies we may be re-entering a lock.

Anyone know how to interpret the rv == 0 assert?

Any other hints on how to debug this would be appreciated.  Other takers?

No ETA.
So whatever thread took the lock should have signed its thread-id somewhere in
the PRLock structure, I think (lock->owner?).

Another way to attack this is to see who calls PR_Lock and PR_Unlock on the lock
that's being wrapped with an auto-lock.  What is that lock, and how many lock
and unlock calls are there?

/be
fwiw, rv in this case is 22; EDEADLK from the pthreads man page.
in case someone encounters a crash on linux in which the trace mentions AIM,
i've filed this internal bug: http://bugscape/show_bug.cgi?id=1169

for the past several days i consistently crash the linux commercial bits when i
quit the browser. here's the trace i get:

nsCAimDataSource::Initialize() 
nsCAimDataSource::FinalConstruct() 
nsCAimDataSource::Create() 
nsCCoolGlue::AimDataSource() 
NotifyChildrenOfStateChange() 
nsCAimSession::Initialize() 
nsCAimSession::FinalConstruct() 
nsCAimSession::Create() 
nsCCoolGlue::AimSession() 
nsCAimAdminManager::Uninitialize() 
nsCAimAdminManager::~nsCAimAdminManager() 
Release() 
libxpcom.so + 0x7a1ff (0x400bc1ff) 
nsCCoolGlue::Uninitialize() 
nsCCoolGlue::~nsCCoolGlue() 
Release() 
libxpcom.so + 0x7a1ff (0x400bc1ff) 
nsCIMManager::Uninitialize() 
nsCIMManager::~nsCIMManager() 
nsCIMManager::Release() 
libxpcom.so + 0x709f4 (0x400b29f4) 
libxpcom.so + 0x409f7 (0x400829f7) 
libplds4.so + 0x1410 (0x4015d410) 
libxpcom.so + 0x40a70 (0x40082a70) 
libxpcom.so + 0x40dc3 (0x40082dc3) 
libxpcom.so + 0x40ce7 (0x40082ce7) 
libxpcom.so + 0x70ace (0x400b2ace) 
libxpcom.so + 0x70b3d (0x400b2b3d) 
libxpcom.so + 0x711e9 (0x400b31e9) 
libxpcom.so + 0x3c527 (0x4007e527) 
mozilla-bin + 0x56fb (0x0804d6fb) 
libc.so.6 + 0x189cb (0x402439cb) 
Adding topcrash keyword, as this crash has made it to the list of top talkback 
crashes.
Keywords: topcrash
This bug is not longer occurs on Linux with 2000-06-14-08-M17 commerical build
I'm still seeing the original crash (not the AIM one) in my Windows debug build 
from this morning.
I'm still seeing the crash on initial mail file->quit with 061608 build under NT


I haven't seen any activity on this dogfood+ bug in over a week. Any updates
before the next seamonkey leads meeting would be much appreciated. Thanks....
messenger only? I see crashes when dong File | Quit on browser also...
I now see this (still as 'Assertion failure: 0 == rv, at ptsynch.c:168') just by
starting up and quitting the browser.  I've also seen:
Assertion failure: OBJ_GET_CLASS(cx, obj)->flags & JSCLASS_HAS_PRIVATE, at
jsapi.c:1381, but I think it's the same problem.


This looks like part of it:

xpcjsruntime.cpp:106
    if(mMapLock)
        PR_DestroyLock(mMapLock);

the mJSRuntimeService destructor causes a js garbage collection; this results in
an nsXPCWrappedNativeClass finalizer being called.  The finalizer tries to use
mMapLock in an autolock, and nspr asserts.

mMapLock is the lock used within the nsXPCWrappedNativeClass finalizer. If I
comment out the PR_DestroyLock() call, then I don't see a crash on startup!

I don't think leaking the lock is a sound workaround, because there's obviously
something wrong if we're still freeing nsXPCWrappedNativeClasses after XPConnect
itself has shutdown.  In

xpcModuleDtor(nsIModule* self)
{
    // Release our singletons
    nsXPConnect::ReleaseXPConnectSingleton();
    nsXPCThreadJSContextStackImpl::FreeSingleton();
    nsJSRuntimeServiceImpl::FreeSingleton();
}

... the lock gets freed in ReleaseXPConnectSingleton, and the offending
finalizer happens in nsJSRuntimeServiceImpl::FreeSingleton.  Reordering them
won't work, as the checkin comment for the first line documents that it was
moved there to fix 25093.

Options are:

- Leak the lock, and see what else it fixes (I've only addressed one of the
crash-on-quit traces in this bug; others may be entirely different issues.)

- Figure out why we still have live XPConnected objects in the js gc heap. 
(Compiling xpcjsruntime.cpp with XPC_DUMP_AT_SHUTDOWN defined reports:
deleting XPCJSRuntime with 9 live JSContexts
deleting XPCJSRuntime with 10 live nsXPCWrappedNativeClass)


I'd appreciate help from anyone experienced at debugging leaked XPConnect
objects.

Looks like something similar came up before with 37058.  CCing rayw, in case
there's a connection.
It's worth mentioning that there's no less than three different stack traces in
this bug, and it's pretty likely that they're not all related.  We might need
new bugs for some.
mccabe...suggestions for the best way to split this up?  Yikes
M16 has been out for a while now, these bugs target milestones need to be 
updated.
Whiteboard: [dogfood+][nsbeta2+] → [dogfood+][nsbeta2+] [ETA later today]
Adjusting whitboard to have an absolute date (6/27) rather than a relative date 
("today")
Whiteboard: [dogfood+][nsbeta2+] [ETA later today] → [dogfood+][nsbeta2+] [ETA 6/27]
I've been looking at this. I can't reproduce it on NT. I can't see how it would 
get into this state. I'll dig deeper.
Attached patch proposed fix — — Splinter Review 

    
    

    
  
Fix attached. The important part is in 
nsXPCWrappedNative::SystemIsBeingShutDown():

+    // Notify other wrappers in the chain.
+    if(mNext)
+        mNext->SystemIsBeingShutDown();

The rest is debug only check code to detect this sort of problem.

At shutdown time the scope objects notify the wrappers in the scope that 
shutdown is occuring. The problem is that I failed to account for the fact that 
the scopes have tables of pointers to only the first wrapper for each object. In 
some cases these wrappers are in chains - to handle objects implementing 
multiple interfaces. The fix is to propagate the SystemIsBeingShutDown call 
along the chain when present.
Assignee: mccabe → jband
Whiteboard: [dogfood+][nsbeta2+] [ETA 6/27] → [dogfood+][nsbeta2+] [fix in hand]

    
  
Status: NEW → ASSIGNED

    
    

    
  
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: [dogfood+][nsbeta2+] [fix in hand] → [dogfood+][nsbeta2+]

    
    

    
  
Reopening bug because i've reproduced this on the latest linux build commercial 
2000-07-05-08-M17. Reproducable all the time.
Status: RESOLVED → REOPENED
OS: All → Linux
Hardware: All → PC
Resolution: FIXED → ---

    
    

    
  
I can confirm this with 2000070508 Mozilla build on NT.  I crash on File|Quit
from Messenger.

    
    

    
  
I looks like this bug has stacks showing various crash locations. I believe I 
fixed the crash in xpconnect. Can someone get a stack on the current crash so we 
can figure out who should own this bug?

    
    

    
  
Alek or Fenella - can you get a talkback report of this crash on Linux?

    
    

    
  
still see this on linux commercial build 2000-07-07-08-M17 here is the stack 
trace:
  
   nsContainerFrame::Destroy() 
                                                  
     
   ViewportFrame::Destroy() 
                                                  
     
   FrameManager::~FrameManager() 
                                                  
     
   FrameManager::Release() 
                                                  
     
   PresShell::~PresShell() 
                                                  
     
   PresShell::Release() 
                                                  
     
   nsCOMPtr_base::~nsCOMPtr_base() 
                                                  
     
   DocumentViewerImpl::~DocumentViewerImpl() 
                                                  
     
   DocumentViewerImpl::Release() 
                                                  
     
   nsCOMPtr_base::assign_with_AddRef() 
                                                  
     
   nsDocShell::Destroy() 
                                                  
     
   nsWebShell::Destroy() 
                                                  
     
   nsXULWindow::Destroy() 
                                                  
     
   nsWebShellWindow::Destroy() 
                                                  
     
   nsWebShellWindow::Close() 
                                                  
     
   nsAppShellService::~nsAppShellService() 
                                                  
     
   nsAppShellService::Release() 
                                                  
     
   nsXPCWrappedNative::~nsXPCWrappedNative() 
                                                  
     
   nsXPCWrappedNative::Release() 
                                                  
     
   nsXPCWrappedNative::JSObjectFinalized() 
                                                  
     
   WrappedNative_Finalize() 
                                                  
     
   js_FinalizeObject() 
                                                  
     
   js_GC() 
                                                  
     
   js_ForceGC() 
                                                  
     
   js_DestroyContext() 
                                                  
     
   JS_DestroyContext() 
                                                  
     
   mozJSComponentLoader::~mozJSComponentLoader() 
                                                  
     
   mozJSComponentLoader::Release() 
                                                  
     
   nsSupportsHashtable::ReleaseElement() 
                                                  
     
   _hashEnumerate__FP11PLHashEntryiPv() 
                                                  
     
   libplds4.so + 0x1410 (0x4015d410) 
                                                  
     
   nsHashtable::Enumerate() 
                                                  
     
   nsSupportsHashtable::~nsSupportsHashtable() 
                                                  
     
   nsComponentManagerImpl::Shutdown() 
                                                  
     
   NS_ShutdownXPCOM() 
                                                  
     
   main() 
                                                  
     
   libc.so.6 + 0x181eb (0x402451eb) 
                                                  

    
    

    
  
Anyone want to claim this?

    
    

    
  
Marking this a dup. We are going to keep having shutdown bugs. We are going to 
keep fixing them. They are not all the same bug.

*** This bug has been marked as a duplicate of 43472 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE

    
    

    
  
Mark it verified/dup.
Status: RESOLVED → VERIFIED

    
    

    
  
Changing summary...still seen on commercial Linux build 2000-07-13-08-M17
Summary: All platforms messenger crashes when do a File|Quit → On linux messenger crashes when do a File|Quit
Product: MailNews → Core
Product: Core → MailNews Core

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: