Closed
Bug 39858
Opened 25 years ago
Closed 25 years ago
On linux messenger crashes when do a File|Quit
Categories
(MailNews Core :: Backend, defect, P3)
Tracking
(Not tracked)
M16
People
(Reporter: fenella, Assigned: jband_mozilla)
References
Details
(Keywords: crash, smoketest, topcrash, Whiteboard: [dogfood+][nsbeta2+])
Attachments
(1 file)
(deleted),
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.
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
Comment 2•25 years ago
|
||
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
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)
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]
Comment 10•25 years ago
|
||
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
Comment 11•25 years ago
|
||
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.
Comment 13•25 years ago
|
||
I can reproduce this bug on Mac 2000-05-22-08-M16 comm build on both IMAP and POP.
Reporter | ||
Comment 14•25 years ago
|
||
Linux (2000-05-22-08 M16) Win (2000-05-22-09 M16) This build can be reproduced in today's builds too.
Comment 15•25 years ago
|
||
I see this happening on other apps when you quit also, like Composer and the browser.
Reporter | ||
Comment 16•25 years ago
|
||
Mac (2000-05-22-08 M16) I still do not see any crash on Mac. I tried it many times using Esther's steps.
Comment 17•25 years ago
|
||
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.
Comment 19•25 years ago
|
||
This crash happens when quiting any of the apps, not just mailnews. I need to find the right owner for this.
Target Milestone: --- → M16
Comment 20•25 years ago
|
||
I just tried this on Win2K and MacOS with fresh builds and I don't see a crash in messenger or anything else.
Comment 21•25 years ago
|
||
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.
Comment 22•25 years ago
|
||
setting ETA. I'm out this week at mail connect.
Whiteboard: [dogfood+] → [dogfood+] ETA: 6/6
Comment 23•25 years ago
|
||
Saari: Can you confirm that you could not reproduce with a non-debug build? Thanks, Jim
Comment 24•25 years ago
|
||
I saw this crash today quitting aim with browser in background on win32 2000-05-31-09M16 build (WinNT)
Reporter | ||
Comment 25•25 years ago
|
||
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.
Comment 26•25 years ago
|
||
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
Reporter | ||
Comment 28•25 years ago
|
||
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.
Reporter | ||
Comment 29•25 years ago
|
||
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?
Comment 30•25 years ago
|
||
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").
Updated•25 years ago
|
Whiteboard: [dogfood+] ETA: 6/6 → [dogfood+][beta2+] ETA: 6/6
Whiteboard: [dogfood+][beta2+] ETA: 6/6 → [dogfood+][nsbeta2+] ETA: 6/6
Comment 31•25 years ago
|
||
Fenella - no need to update this bug every day if no one has worked on the bug
Comment 32•25 years ago
|
||
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?
Comment 33•25 years ago
|
||
Unless it's a different crash, I still get crashes on File quit with AIM or browser using todays builds. :-(
Comment 35•25 years ago
|
||
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.
Comment 37•25 years ago
|
||
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.
Comment 38•25 years ago
|
||
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
Comment 39•25 years ago
|
||
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?
Comment 40•25 years ago
|
||
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
Comment 41•25 years ago
|
||
reassigning to mccabe based on Brendan's comments.
Assignee: mscott → mccabe
Comment 42•25 years ago
|
||
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+]
Comment 43•25 years ago
|
||
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.
Comment 45•25 years ago
|
||
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.
Comment 46•25 years ago
|
||
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
Comment 48•25 years ago
|
||
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)
Comment 49•25 years ago
|
||
Adding topcrash keyword, as this crash has made it to the list of top talkback crashes.
Keywords: topcrash
Comment 50•25 years ago
|
||
This bug is not longer occurs on Linux with 2000-06-14-08-M17 commerical build
Comment 51•25 years ago
|
||
I'm still seeing the original crash (not the AIM one) in my Windows debug build from this morning.
Comment 52•25 years ago
|
||
I'm still seeing the crash on initial mail file->quit with 061608 build under NT
Comment 53•25 years ago
|
||
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....
Comment 55•25 years ago
|
||
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.
Comment 56•25 years ago
|
||
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.
Comment 58•25 years ago
|
||
M16 has been out for a while now, these bugs target milestones need to be updated.
Updated•25 years ago
|
Whiteboard: [dogfood+][nsbeta2+] → [dogfood+][nsbeta2+] [ETA later today]
Comment 59•25 years ago
|
||
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]
Assignee | ||
Comment 60•25 years ago
|
||
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.
Assignee | ||
Comment 61•25 years ago
|
||
Assignee | ||
Comment 62•25 years ago
|
||
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]
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 63•25 years ago
|
||
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Whiteboard: [dogfood+][nsbeta2+] [fix in hand] → [dogfood+][nsbeta2+]
Comment 64•25 years ago
|
||
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 → ---
Comment 65•25 years ago
|
||
I can confirm this with 2000070508 Mozilla build on NT. I crash on File|Quit from Messenger.
Assignee | ||
Comment 66•25 years ago
|
||
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?
Comment 68•25 years ago
|
||
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)
Comment 70•25 years ago
|
||
Is this duplicate of Bug # 43472 ? ccing:- nisheeth@netscape.com,akkana@netscape.com
Assignee | ||
Comment 71•25 years ago
|
||
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: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
Comment 73•25 years ago
|
||
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
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•