I'm crashing on exit. The crashing is pretty consistent, as is the stack trace. Running 2001-09-03-03 commercial trunk on WinNT with multiple profiles and Turbo on. Steps to reproduce. 1. Start the build. Note - I have multiple profiles and Turbo is turned on. 2. Do some browsing. 3. Exit. Expected result: You exit cleanly, and Turbo remains enabled (as evidenced by icon on the sys tray.) Actual result: Crash + Turbo exits. Talkback incidents: 35081179 and 35044644. Stack trace for 35081179: pref_ClearUserPref [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.c, line 1129] PL_HashTableEnumerateEntries [../../../lib/ds/plhash.c, line 430] PREF_ClearAllUserPrefs [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.c, line 1145] nsPrefService::ResetUserPrefs [d:\builds\seamonkey\mozilla\modules\libpref\src\nsPrefService.cpp, line 274] nsPrefService::Observe [d:\builds\seamonkey\mozilla\modules\libpref\src\nsPrefService.cpp, line 150] nsObserverService::Notify [d:\builds\seamonkey\mozilla\xpcom\ds\nsObserverService.cpp, line 238] nsProfile::SetCurrentProfile [d:\builds\seamonkey\mozilla\profile\src\nsProfile.cpp, line 1142] netscp6.exe + 0x4d0b (0x00404d0b) netscp6.exe + 0x48be (0x004048be) netscp6.exe + 0x4110 (0x00404110) USER32.dll + 0x19d0 (0x77e719d0) USER32.dll + 0x1c109 (0x77e8c109) ntdll.dll + 0x163a3 (0x77f763a3) USER32.dll + 0x1bd8 (0x77e71bd8) nsAppShell::Run [d:\builds\seamonkey\mozilla\widget\src\windows\nsAppShell.cpp, line 113] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 456] netscp6.exe + 0x17ca (0x004017ca) netscp6.exe + 0x121a (0x0040121a) netscp6.exe + 0x3732 (0x00403732) KERNEL32.dll + 0x1ba06 (0x77f1ba06)

Looking at it. This is going to be tough because that functionality (clearing user prefs on a profile shutdown) has been there for some time.

Sol, neither Conrad or I can reproduce this. Is this the first build you've seen this problem on? Or has this been an ongoing problem for you?

Brian - I was a bit of a slug about using trunk builds. I stayed on 6.1 for quite some time. This was the first build I saw the problem on, but I can't recall for sure whether or not I used any post 6.1 builds prior to using 2001-09-03-03. FWIW - I have a very old profile that I'm running. It may be the same profile I've been using for 3 years now.

i cannot repro this using a migrated profile [i also have multiple profiles] with turbo on --tested on winNT, 2001.09.04.00-comm bits.

Sol, can you either attach or email me your prefs.js file from your profile?

Sol, could you please try this with a new profile? Also, just to be clear-does it crash with turbo off?

Peter: I sent Brian my prefs.js in an email. I'm continuing to see the crash using 2001-09-19-05. I have not been able to reproduce the crash in a new profile, but it seems that I must be working in a profile for some time before exiting the client in order to trigger the crash. I have not tried running without Turbo and seeing if I can still reproduce the crash. I'll try that next.

Placing "Turbo+" in Status Whiteboard, and marking nsbranch+ for Trudelle's short list query. Pls remove Turbo+ and nsbranch- if this is no longer on the short list.

terri, have you encountered this situation?

related: bug 100846

Still seeing this on 2001-09-24 commercial on Win98. Talkback incident ID 35814198.

Multi profile support is out, so this is now nsbranch-

This is a topcrash for the N620 branch. I understand the turbo is out for eMojo, but for tracking purposes, adding topcrash keyword and Trunk & N620 [@ pref_ClearUserPref] to summary. Here is the Talkback data from the Netscape6.20 branch: pref_ClearUserPref 6 BBID range: 35598484 - 35832550 Min/Max Seconds since last crash: 155 - 25965 Min/Max Runtime: 155 - 45920 Crash data range: 2001-09-19 to 2001-09-24 Build ID range: 2001091705 to 2001092405 Stack Trace: pref_ClearUserPref [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.c line 1129] PL_HashTableEnumerateEntries [../../../lib/ds/plhash.c line 430] PREF_ClearAllUserPrefs [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.c line 1143] nsPrefService::ResetUserPrefs [d:\builds\seamonkey\mozilla\modules\libpref\src\nsPrefService.cpp line 200] nsPrefService::Observe [d:\builds\seamonkey\mozilla\modules\libpref\src\nsPrefService.cpp line 153] nsObserverService::Notify [d:\builds\seamonkey\mozilla\xpcom\ds\nsObserverService.cpp line 238] nsProfile::SetCurrentProfile [d:\builds\seamonkey\mozilla\profile\src\nsProfile.cpp line 1142] nsProfile::StartApprunner [d:\builds\seamonkey\mozilla\profile\src\nsProfile.cpp line 1821] XPTC_InvokeByIndex [d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp line 139] XPCWrappedNative::CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp line 1954] XPC_WN_CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp line 1263] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 809] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 2720] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 825] js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 900] JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c line 3364] nsJSContext::CallEventHandler [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp line 959] nsJSEventListener::HandleEvent [d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp line 140] nsEventListenerManager::HandleEventSubType [d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp line 1197] nsEventListenerManager::HandleEvent [d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp line 2189] nsXULElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp line 3711] PresShell::HandleDOMEventWithTarget [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5758] nsButtonBoxFrame::MouseClicked [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsButtonBoxFrame.cpp line 181] nsButtonBoxFrame::HandleEvent [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsButtonBoxFrame.cpp line 128] PresShell::HandleEventInternal [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5727] PresShell::HandleEventWithTarget [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5680] nsEventStateManager::CheckForAndDispatchClick [d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp line 2466] nsEventStateManager::PostHandleEvent [d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp line 1552] PresShell::HandleEventInternal [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5731] PresShell::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5635] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp line 377] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp line 2062] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp line 68] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 732] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 749] nsWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 4264] ChildWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 4514] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 3251] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 997] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x24407 (0xbff94407) 0x0068848e Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/libpref/src/prefapi.c line : 1129 (35832550) Comments: Crashed restarting with Turbo running (35829307) Comments: sending mail. Then shut down. (35814198) Comments: Crash on startup with Turbo on (35615052) Comments: Crashed on restart - Turbo enabled (35612904) Comments: Crashed on exit and then restart with Turbo enabled (35598484) Comments: Crash on exit and restart with Turbo enabled

cc'ing brendan who, I believe, has worked on both the hash table and the turbo code recently. Brendan, does this ring any bells or raise any flags?

Looks to me like, on line 1129, pref != nsnull but is some bogus (freed) value. I doubt it's a hash table problem but pref object lifetime problem.

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

FWIW I am getting this crash on startup fairly consistently...

Brian, we're you able to reproduce this with sol's prefs.js file? I'll start looking at this too. We need to nail this.

No I wasn't, nor do I think it's related to anything specific to his file. I spoke with Gagan yesterday. He claims (though he couldn't demonstrate it ;)) that it happens fairly regularly for him on launch. I noted that he has multiple profiles and thus launches via the profile mgr... I'm going to set my machine up the same way to see if it improves my chances of reproducing the crash.

Gagan - can you still repro this? I'm curious if the fix to bug 89465 did anything for this.

setting to 0.9.7. top crash, we should try to figure this out soon!

I can't reproduce, but here's what I think will fix the problem the old problem was probably that we weren't clearing stringVal, so that a new pref without a default value might have a bogus value in .userVal or something. Anyway, the new problem is that when we recycle PrefHashEntrys, we weren't clearing out the old entry.

I was able to repro this twice before applying the patch. Since applying the patch, I can't :-)

yay! Can I get some reviews? brendan, this is a bug in my use of pldhash.. basically I wasn't clearing out the entry in the ClearEntry callback.

Comment on attachment 60338 [details] [diff] [review] the fix? woohoo! r=bnesse.

Comment on attachment 60338 [details] [diff] [review] the fix? Duh, I should have caught that -- sorry about that. Usually I just call PL_DHashClearEntryStub, which calls memset(entry, 0, table->entrySize) for me -- but inlining is fine too. /be

checked this in with the (re-vamped) fix to bug 112708