Build ID: 1999090808 Platform: RH Linux 6, Windows NT To reproduce: - Launch apprunner - Open the prefs - Click Navigator - Change the Home Page pref to something else - Click OK Result: The app crashes. A Talkback report was generated using 'bear@netscape.com'. Expected result: The pref is saved & the app doesn't crash.

Matt, wassup with this!

I saw this too, yesterday, on linux.

hummm... this is working on window for me. I'll look at it for linux.

Using the 1999090908 build on NT, it still crashes for me. To crash it easily, change the Home page to any other URL and click OK.

Still crashing, 1999091308-M11 build on Linux.

I just downloaded todays build and changed the homepage in the prefs and it did not crash. I did this with linux and windows. Is this something to do with your prefs.js file. maybe it is corrupted.

Good question. I deleted all profiles and prefs.js files in the users50 folder and the moz*.dat file, reinstalled this morning's build (1999091310 M10) on Windows NT, and tried again. And lo and behold, it did NOT crash. It also is now working on Linux for me. Still, it does worry me that it crashes so often...

fixed since i think i fixed it but some how it got corrupted with your files. If you see it again open a new bug. thx

This seems to have not been fixed suddenly, based on the bug mail I'm getting from others filing similar bugs.

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

Can we get a reproducable test case? I think that there was a few bad days that corrupted the .js file. Then since that day those people effected have been effected for some time until they deleted there .js file. If the file still gets corrupted with the current builds then we do still have this bug. cpratt, do you know and can you find out for me?

There is another similiar bug filed by a developer (can't find that bug, sorry) who removed moz*.dat and Users50 files/folders and still got this crash. So... I don't think it's fixed, but I haven't seen it.

Move this to M12 until we can get a reproducible test case ...

Using the 1999092013-M11 build on Linux, this happens to me reliably and consistently. The test case I have right now is simple: - download the build - untar it - change to the 'package' directory - run ./mozilla-apprunner.sh - open the prefs - change the home page - click OK - crash

can we get a stack trace on this?

http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=43&cp=1&ck1= SUser+email+address&cd1=%25bear%40marmot%2Enet%25&co1=like&bbid=13900718

Here's the windows trace from cpratt's talkback report: Call Stack: (Signature = nsStringArray::~nsStringArray fa1ba2d9) nsStringArray::~nsStringArray [d:\builds\seamonkey\mozilla\xpcom\ds\nsVoidArray.cpp, line 241] nsStringArray::`scalar deleting destructor' PrefChangedCallback [d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp, line 55] pref_DoCallback [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.c, line 2295] pref_HashPref [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.c, line 1866] PrefChangedCallback [d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp, line 55] pref_DoCallback [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.c, line 2295] pref_HashPref [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.c, line 1866] PREF_SetCharPref [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.c, line 714] pref_copyTree [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.c, line 2172] pref_copyTree [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.c, line 2149] pref_copyTree [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.c, line 2149] PREF_CopyPrefsTree [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.c, line 2230] nsPref::CopyPrefsTree [d:\builds\seamonkey\mozilla\modules\libpref\src\nsPref.cpp, line 893] nsPrefWindow::SavePrefs [d:\builds\seamonkey\mozilla\xpfe\components\prefwindow\src\nsPrefWindow.cpp, line 741] XPTC_InvokeByIndex [d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp, line 135] nsXPCWrappedNativeClass::CallWrappedMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativeclass.cpp, line 752] WrappedNative_CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp, line 171] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 656] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2234] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 676] js_InternalCall [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 749] JS_CallFunction [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 2636] nsJSContext::CallFunction [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 234] nsJSEventListener::HandleEvent [d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 107] nsEventListenerManager::HandleEvent [d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line 653] RDFElementImpl::HandleDOMEvent [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFElement.cpp, line 2876] nsEventStateManager::CheckForAndDispatchClick [d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line 950] nsEventStateManager::PostHandleEvent [d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line 420] PresShell::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 2095] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 828] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1665] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 63] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 342] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 359] nsWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3223] ChildWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3439] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2441] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 448] USER32.dll + 0x1820 (0x77e71820)

here's the linux trace, with no symbol info :-( Call Stack: (Signature = libraptorhtml.so + 0x2d6674 (0x40b77674) eff969f3) libraptorhtml.so + 0x2d6674 (0x40b77674) libraptorhtml.so + 0x2d5e70 (0x40b76e70) libpref.so + 0x681a (0x4071c81a) libpref.so + 0x5f04 (0x4071bf04) libpref.so + 0x477f (0x4071a77f) libpref.so + 0x6616 (0x4071c616) libpref.so + 0x669d (0x4071c69d) libpref.so + 0x669d (0x4071c69d) libpref.so + 0x66ed (0x4071c6ed) libpref.so + 0x822b (0x4071e22b) libprefwindow.so + 0x2fe4 (0x412f1fe4) libxpcom.so + 0x5f26a (0x400ee26a) libxpconnect.so + 0x21efd (0x40e51efd) libxpconnect.so + 0x22ec8 (0x40e52ec8) libmozjs.so + 0x26e01 (0x4005ce01) libmozjs.so + 0x2d00a (0x4006300a) libmozjs.so + 0x26e54 (0x4005ce54) libmozjs.so + 0x2702d (0x4005d02d) libmozjs.so + 0xfd4c (0x40045d4c) libjsdom.so + 0x1fabf (0x4038dabf) libjsdom.so + 0x41e8e (0x403afe8e) libraptorhtml.so + 0x15c915 (0x409fd915)

this seems to happen consistently the first time you run a build on a new profile and then change a setting like your home page.

Still happens on the 1999101408 build, Win32, after deleting moz*.dat and Users50.

Looks like a backend prefs bug

Putting on [PDT+] radar.

I am able to get the crash on windows. I deleted mozregistry.dat and created a new profile. Changed the home page and clicked ok. There is no crash. Should I be doing something different? Does this happen consistently, everytime a new profile is created?

On today's 101508 Linux build, this happens *every time* you try to change the home page in prefs and click OK. Whether it is a new profile or not. I can change other prefs without crashing however.

Still happens to me in the 1999101508 build. See also: http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=62&cp=2&ck1= SUser+email+address&cd1=%25bear%40marmot%2Enet%25&co1=like&bbid=14238926

Ok, I can get it to crash on 10/15 windows build. Here is the stack trace. PREF_SetCharPref(const char * 0x03402060, const char * 0x034036b0) line 715 + 17 bytes pref_copyTree(const char * 0x01b48ae8, const char * 0x01b49248, const char * 0x0291dcb0) line 2172 + 13 bytes pref_copyTree(const char * 0x01b48ae8, const char * 0x01b49248, const char * 0x0290f7da) line 2216 + 17 bytes pref_copyTree(const char * 0x01b48ae8, const char * 0x01b49248, const char * 0x01b48ae8) line 2216 + 17 bytes PREF_CopyPrefsTree(const char * 0x01b48ae8, const char * 0x01b49248) line 2231 + 17 bytes nsPref::CopyPrefsTree(nsPref * const 0x0200d4c0, const char * 0x01b48ae8, const char * 0x01b49248) line 893 + 13 bytes nsPrefWindow::SavePrefs(nsPrefWindow * const 0x031f4650) line 751 XPTC_InvokeByIndex(nsISupports * 0x031f4650, unsigned int 6, unsigned int 0, nsXPTCVariant * 0x0012c8d4) line 135 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x031f7560, nsXPCWrappedNative * 0x03325260, const XPCNativeMemberDescriptor * 0x03325310, nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0, long * 0x028da04c, long * 0x0012ca74) line 782 + 44 bytes WrappedNative_CallMethod(JSContext * 0x031f7560, JSObject * 0x028a1a48, unsigned int 0, long * 0x028da04c, long * 0x0012ca74) line 186 + 34 bytes js_Invoke(JSContext * 0x031f7560, unsigned int 0, unsigned int 0) line 672 + 26 bytes js_Interpret(JSContext * 0x031f7560, long * 0x0012d2ec) line 2248 + 15 bytes js_Invoke(JSContext * 0x031f7560, unsigned int 1, unsigned int 2) line 688 + 13 bytes js_InternalCall(JSContext * 0x031f7560, JSObject * 0x0289ff18, long 42598176, unsigned int 1, long * 0x0012d46c, long * 0x0012d424) line 765 + 15 bytes JS_CallFunction(JSContext * 0x031f7560, JSObject * 0x0289ff18, JSFunction * 0x03238a20, unsigned int 1, long * 0x0012d46c, long * 0x0012d424) line 2653 + 32 bytes nsJSContext::CallFunction(nsJSContext * const 0x031f62a0, void * 0x0289ff18, void * 0x03238a20, unsigned int 1, void * 0x0012d46c, int * 0x0012d468) line 231 + 39 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x03402fc0) line 103 + 48 bytes nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent * 0x0012d764, nsIDOMEvent * * 0x0012d72c, unsigned int 7, nsEventStatus & nsEventStatus_eIgnore) line 646 + 21 bytes RDFElementImpl::HandleDOMEvent(RDFElementImpl * const 0x0322ff90, nsIPresContext & {...}, nsEvent * 0x0012d764, nsIDOMEvent * * 0x0012d72c, unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 2905 nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const 0x0324c600, nsIPresContext & {...}, nsMouseEvent * 0x0012dad8, nsEventStatus & nsEventStatus_eIgnore) line 992 + 42 bytes nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x0324c600, nsIPresContext & {...}, nsGUIEvent * 0x0012dad8, nsIFrame * 0x0324daf0, nsEventStatus & nsEventStatus_eIgnore, nsIView * 0x0322b480) line 467 + 24 bytes PresShell::HandleEvent(PresShell * const 0x0322b064, nsIView * 0x0322b480, nsGUIEvent * 0x0012dad8, nsEventStatus & nsEventStatus_eIgnore) line 2165 + 43 bytes nsView::HandleEvent(nsView * const 0x0322b480, nsGUIEvent * 0x0012dad8, unsigned int 28, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 834 nsViewManager::DispatchEvent(nsViewManager * const 0x0322b6a0, nsGUIEvent * 0x0012dad8, nsEventStatus & nsEventStatus_eIgnore) line 1739 HandleEvent(nsGUIEvent * 0x0012dad8) line 63 nsWindow::DispatchEvent(nsWindow * const 0x0322b344, nsGUIEvent * 0x0012dad8, nsEventStatus & nsEventStatus_eIgnore) line 401 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012dad8) line 422 nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3388 + 21 bytes ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3606 nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 25165912, long * 0x0012dd00) line 2620 + 24 bytes nsWindow::WindowProc(HWND__ * 0x02140876, unsigned int 514, unsigned int 0, long 25165912) line 579 + 27 bytes USER32! 77e71250() nsNativeSelectControlFra

The crash is happening in nsPresContext::PreferenceChanged(..) nsPresContext::PreferenceChanged(const char* aPrefName) { // Initialize our state from the user preferences GetUserPreferences(); if (mShell) { // Have the root frame's style context remap its style based on the // user preferences nsIFrame* rootFrame; mShell->GetRootFrame(&rootFrame); // We get a crash at this line if (rootFrame) { nsIStyleContext* rootStyleContext; rootFrame->GetStyleContext(&rootStyleContext); rootStyleContext->RemapStyle(this); NS_RELEASE(rootStyleContext); // Force a reflow of the root frame // XXX We really should only do a reflow if a preference that affects // formatting changed, e.g., a font change. If it's just a color change // then we only need to repaint... mShell->StyleChangeReflow(); } } } It looks like a memory corruption issue. This crash also happens when settings are changed in the appearance/fonts or appearance/colors panels. nsPresContext::PreferenceChanged(const char * 0x02c68fd0) line 233 + 19 bytes PrefChangedCallback(const char * 0x02c68fd0, void * 0x02b06420) line 55 pref_DoCallback(const char * 0x02c68fd0) line 2296 + 17 bytes pref_HashPref(const char * 0x02c68fd0, PrefValue {...}, int 32, int 1) line 1867 + 9 bytes PREF_SetCharPref(const char * 0x02c68fd0, const char * 0x02c68b80) line 715 + 17 bytes pref_copyTree(const char * 0x02b28aa0, const char * 0x02b29190, const char * 0x0211ee48) line 2172 + 13 bytes pref_copyTree(const char * 0x02b28aa0, const char * 0x02b29190, const char * 0x0219d452) line 2216 + 17 bytes pref_copyTree(const char * 0x02b28aa0, const char * 0x02b29190, const char * 0x02b28aa0) line 2216 + 17 bytes PREF_CopyPrefsTree(const char * 0x02b28aa0, const char * 0x02b29190) line 2231 + 17 bytes nsPref::CopyPrefsTree(nsPref * const 0x00d212a0, const char * 0x02b28aa0, const char * 0x02b29190) line 893 + 13 bytes nsPrefWindow::SavePrefs(nsPrefWindow * const 0x02a480e0) line 751 XPTC_InvokeByIndex(nsISupports * 0x02a480e0, unsigned int 6, unsigned int 0, nsXPTCVariant * 0x0012c7e8) line 135 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x02a4f4a0, nsXPCWrappedNative * 0x02b8f0b0, const XPCNativeMemberDescriptor * 0x02b8f160, nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0, long * 0x0210de94, long * 0x0012c98c) line 791 + 43 bytes WrappedNative_CallMethod(JSContext * 0x02a4f4a0, JSObject * 0x00f98240, unsigned int 0, long * 0x0210de94, long * 0x0012c98c) line 186 + 34 bytes js_Invoke(JSContext * 0x02a4f4a0, unsigned int 0, unsigned int 0) line 672 + 26 bytes js_Interpret(JSContext * 0x02a4f4a0, long * 0x0012d204) line 2248 + 15 bytes js_Invoke(JSContext * 0x02a4f4a0, unsigned int 1, unsigned int 2) line 688 + 13 bytes js_InternalCall(JSContext * 0x02a4f4a0, JSObject * 0x00f38488, long 15959184, unsigned int 1, long * 0x0012d384, long * 0x0012d33c) line 765 + 15 bytes JS_CallFunction(JSContext * 0x02a4f4a0, JSObject * 0x00f38488, JSFunction * 0x02a81800, unsigned int 1, long * 0x0012d384, long * 0x0012d33c) line 2653 + 32 bytes nsJSContext::CallFunction(nsJSContext * const 0x02a4ed20, void * 0x00f38488, void * 0x02a81800, unsigned int 1, void * 0x0012d384, int * 0x0012d380) line 231 + 39 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x02c636b0) line 103 + 48 bytes nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent * 0x0012d67c, nsIDOMEvent * * 0x0012d644, unsigned int 7, nsEventStatus & nsEventStatus_eIgnore) line 646 + 21 bytes RDFElementImpl::HandleDOMEvent(RDFElementImpl * const 0x02a80380, nsIPresContext & {...}, nsEvent * 0x0012d67c, nsIDOMEvent * * 0x0012d644, unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 2925 nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const 0x02a96cd0, nsIPresContext & {...}, nsMouseEvent * 0x0012d9f0, nsEventStatus & nsEventStatus_eIgnore) line 992 + 42 bytes nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x02a96cd0, nsIPresContext & {...}, nsGUIEvent * 0x0012d9f0, nsIFrame * 0x02a96270, nsEventStatus & nsEventStatus_eIgnore, nsIView * 0x02a75cf0) line 467 + 24 bytes PresShell::HandleEvent(PresShell * const 0x02a758d4, nsIView * 0x02a75cf0, nsGUIEvent * 0x0012d9f0, nsEventStatus & nsEventStatus_eIgnore) line 2167 + 43 bytes nsView::HandleEvent(nsView * const 0x02a75cf0, nsGUIEvent * 0x0012d9f0, unsigned int 28, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 834 nsViewManager::DispatchEvent(nsViewManager * const 0x02a75ec0, nsGUIEvent * 0x0012d9f0, nsEventStatus & nsEventStatus_eIgnore) line 1739 HandleEvent(nsGUIEvent * 0x0012d9f0) line 63 nsWindow::DispatchEvent(nsWindow * const 0x02a75bb4, nsGUIEvent * 0x0012d9f0, nsEventStatus & nsEventStatus_eIgnore) line 401 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012d9f0) line 422 nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3394 + 21 bytes ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3612 nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 24969299, long * 0x0012dc18) line 2626 + 24 bytes nsWindow::WindowProc(HWND__ * 0x077a0a06, unsigned int 514, unsigned int 0, long 24969299) line 579 + 27 bytes USER32! 77e71250() nsHTMLReflowState::ComputeRelativeOffsets(const nsHTMLReflowState *, int, int) line 393

This crash is not happening in today's(10/19/99) builds on NT and linux. Chris, does it still crash for you? Neeti

Seems fine in today's Win32 build. I'd like to hold off for another 1-2 days before marking it verified though...

Seems to be working again, yes. Verified using 1999102708 builds, NT and Linux.

Bulk move of all Pref UI component bugs to new Preferences component. Pref UI component will be deleted.