98736 - Trunk & N620 Crashing on Exit [@ pref_ClearUserPref] [turbo]

Status: RESOLVED FIXED

(Core :: Preferences: Backend, defect)

Description

[sol]

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)

Comment 1

[Conrad Carlen (not reading bugmail)]

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.

Comment 2

[Brian Nesse (gone)]

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?

Comment 3

[sol]

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.

Comment 4

[sairuh (rarely reading bugmail)]

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.

Comment 5

[Brian Nesse (gone)]

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

Comment 6

[Peter Trudelle]

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

Comment 7

[sol]

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.

Comment 8

[Jaime Rodriguez, Jr.]

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.

Comment 9

[sairuh (rarely reading bugmail)]

terri, have you encountered this situation?

Comment 10

[R.K.Aa.]

related: bug 100846

Comment 11

[sol]

Still seeing this on 2001-09-24 commercial on Win98.

Talkback incident ID 35814198.

Comment 12

[Peter Trudelle]

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

Comment 13

[Jay Patel [:jay]]

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

Comment 14

[Brian Nesse (gone)]

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?

Comment 15

[Conrad Carlen (not reading bugmail)]

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.

Comment 16

[Brian Nesse (gone)]

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

Comment 17

[Gagan]

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

Comment 18

[Conrad Carlen (not reading bugmail)]

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.

Comment 19

[Brian Nesse (gone)]

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.

Comment 20

[Conrad Carlen (not reading bugmail)]

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

Comment 21

[Cathleen]

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

Comment 22

[Alec Flett]

Attachment: the fix?

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.

Comment 23

[Conrad Carlen (not reading bugmail)]

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

Comment 24

[Alec Flett]

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 25

[Brian Nesse (gone)]

Comment on attachment 60338 [details] [diff] [review]
the fix?

woohoo! r=bnesse.

Comment 26

[Brendan Eich [:brendan]]

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

Comment 27

[Alec Flett]

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