Closed Bug 196337 Opened 21 years ago Closed 21 years ago

Mozilla crashes on startup with user_pref("nglayout.debug.disable_xul_cache", false); presenting in prefs.js

Categories

(Core :: XUL, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: asherman, Assigned: bryner)

References

Details

(Keywords: crash, regression)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030307
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030307

If the user_pref("nglayout.debug.disable_xul_cache", false); string presents in
prefs.js file, mozilla crashes on start up. And if i look through the prefernces
without changing and click OK button mozilla crashes also with adding this
string into prefs.js. 

Reproducible: Always

Steps to Reproduce:
1. See preferences wiht opening debug group
2. Click OK button
3. Or add this string into the prefs.js file

Actual Results:  
CRASH !!!

Expected Results:  
:)
Not preferences...
Assignee: ccarlen → hyatt
Component: Preferences: Backend → XP Toolkit/Widgets: XUL
Keywords: regression
QA Contact: sairuh → shrir
Seems to be a little fallout from de-COM of XBL. (Reproduced this stack by 
trying to switch to disable in that pref panel).

-> bryner

[Note: I'm planning on removing that bit of UI, and changing the pref name; in 
fact I was going to do this later today. This is still a bug I suppose, 
though].

NTDLL! 77f8ed61()
NTDLL! 77f8ecf1()
nsXBLBinding::ImplementsInterface(nsXBLBinding * const 0x021d2cd0, const nsID & 
{...}, int * 0x0012f43c) line 1590
nsXBLBinding::ImplementsInterface(nsXBLBinding * const 0x021d2c18, const nsID & 
{...}, int * 0x0012f43c) line 1591 + 14 bytes
nsBindingManager::GetBindingImplementation(nsBindingManager * const 0x02736158, 
nsIContent * 0x021f1248, const nsID & {...}, void * * 0x0012f4d0) line 1155
nsXULElement::QueryInterface(nsXULElement * const 0x02736158, const nsID & 
{...}, void * * 0x0012f4d0) line 662 + 15 bytes
nsDOMEventRTTearoff::QueryInterface(nsDOMEventRTTearoff * const 0x02790f20, 
const nsID & {...}, void * * 0x0012f4d0) line 443 + 15 bytes
nsQueryInterface::operator()(const nsQueryInterface * const 0x0012ffb0, const 
nsID & {...}, void * * 0x0012f4d0) line 52
nsCOMPtr_base::assign_from_helper(nsCOMPtr_base * const 0x0012ffb0, const 
nsCOMPtr_helper & {...}, const nsID & {...}) line 81 + 14 bytes
nsXBLPrototypeHandler::ExecuteHandler(nsXBLPrototypeHandler * const 0x0012ffb0, 
nsIDOMEventReceiver * 0x02790f20, nsIDOMEvent * 0x013a0db8) line 358
nsXBLPrototypeHandler::BindingDetached(nsXBLPrototypeHandler * const 
0x0012ffb0, nsIDOMEventReceiver * 0x02790f20) line 497
nsXBLBinding::ExecuteDetachedHandler(nsXBLBinding * const 0x02790f20) line 1047
nsXBLBinding::ExecuteDetachedHandler(nsXBLBinding * const 0x0286e730) line 1050
ExecuteDetachedHandler(PLDHashTable * 0x02736168, PLDHashEntryHdr * 0x022047d4, 
unsigned int 27, void * 0x00000000) line 995
PL_DHashTableEnumerate(PLDHashTable * 0x0000001c, int (PLDHashTable *, 
PLDHashEntryHdr *, unsigned int, void *)* 0x012bc5d6 
ExecuteDetachedHandler(PLDHashTable *, PLDHashEntryHdr *, unsigned int, void 
*), void * 0x00000000) line 604 + 15 bytes
nsBindingManager::ExecuteDetachedHandlers(nsBindingManager * const 0x02736158) 
line 1004 + 13 bytes
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x02736158, 
nsIPresContext * 0x027a7ed8, nsEvent * 0x027bb848, nsIDOMEvent * * 0x0012fa7c, 
unsigned int 7, nsEventStatus * 0x0012fad8) line 776
DocumentViewerImpl::Unload(DocumentViewerImpl * const 0x02789e70) line 1005
nsDocShell::FireUnloadNotification(nsDocShell * const 0x02745500) line 821
nsDocShell::FireUnloadNotification(nsDocShell * const 0x02745500) line 829
nsDocShell::Destroy(nsDocShell * const 0x0273a23c) line 2975
nsWebShell::Destroy(nsWebShell * const 0x0273a23c) line 1243
nsXULWindow::Destroy(nsXULWindow * const 0x0273a23c) line 411
nsWebShellWindow::Destroy(nsWebShellWindow * const 0x0280724c) line 1670 + 6 
bytes
nsChromeTreeOwner::Destroy(nsChromeTreeOwner * const 0x02787564) line 292
GlobalWindowImpl::ReallyCloseWindow(GlobalWindowImpl * const 0x026a83d8) line 
3201
GlobalWindowImpl::CloseWindow(nsISupports * 0x026a83d8) line 4407
nsJSContext::ScriptEvaluated(nsJSContext * const 0x027a3138, int 1) line 1478 + 
7 bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x00df5990, void * 
0x01bad440, void * 0x80000001, unsigned int 2, void * 0x02745838, int * 
0x0012fd7c, int 0) line 1048
GlobalWindowImpl::RunTimeout(GlobalWindowImpl * const 0x0012ffb0, nsTimeoutImpl 
* 0x00000000) line 4751
GlobalWindowImpl::TimerCallback(nsITimer * 0x028035e0, void * 0x027bd3c8) line 
5107
nsTimerImpl::Fire(nsTimerImpl * const 0x0012ffb0) line 382 + 7 bytes
nsAppShell::Run(nsAppShell * const 0x00e30cf0) line 176
nsAppShellService::Run(nsAppShellService * const 0x00e33e58) line 480
main1(int 0, char * * 0x00243f90, nsISupports * 0x00000000) line 1269 + 9 bytes
main(int 2, char * * 0x00243f90) line 1640 + 22 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00400000, char * 0x00133821, 
HINSTANCE__ * 0x00400000) line 1663 + 23 bytes
MOZILLA! WinMainCRTStartup + 308 bytes
Assignee: hyatt → bryner
Status: UNCONFIRMED → NEW
Ever confirmed: true
I don't crash at startup when I start with this pref true, but I do crash when 
I change that pref in the debug panel.

In a debug build, I get a slightly different stack for a crash, and it crashes
in nsXBLPrototypeBinding::BindingDetached() trying to dereference an
uninitialized member |mImplementation|.

nsXBLPrototypeBinding::BindingDetached(nsIDOMEventReceiver * 0x03a23028) line 
421 + 15 bytes
nsXBLBinding::ExecuteDetachedHandler(nsXBLBinding * const 0x044df4a0) line 1047
ExecuteDetachedHandler(PLDHashTable * 0x03a0a4a4, PLDHashEntryHdr * 0x044e2998, 
unsigned int 0, void * 0x00000000) line 995
PL_DHashTableEnumerate(PLDHashTable * 0x03a0a4a4, int (PLDHashTable *, 
PLDHashEntryHdr *, unsigned int, void *)* 0x019f8030 
ExecuteDetachedHandler(PLDHashTable *, PLDHashEntryHdr *, unsigned int, void 
*), void * 0x00000000) line 604 + 34 bytes
nsBindingManager::ExecuteDetachedHandlers(nsBindingManager * const 0x03a0a490) 
line 1004 + 19 bytes
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x03980680, 
nsIPresContext * 0x03a33370, nsEvent * 0x0012f880, nsIDOMEvent * * 0x0012f83c, 
unsigned int 7, nsEventStatus * 0x0012f8a8) line 776
DocumentViewerImpl::Unload(DocumentViewerImpl * const 0x03a0a5c8) line 1003 + 
47 bytes
nsDocShell::FireUnloadNotification(nsDocShell * const 0x03a0cc70) line 819 + 29 
bytes
nsDocShell::Destroy(nsDocShell * const 0x03a0cc84) line 2972
nsWebShell::Destroy(nsWebShell * const 0x03a0cc84) line 1243
nsXULWindow::Destroy(nsXULWindow * const 0x03a0c6f0) line 411
nsWebShellWindow::Destroy(nsWebShellWindow * const 0x03a0c6f0) line 1670 + 9 
bytes
... etc., ...
Keywords: crash
Summary: Mozill crashes on start up with user_pref("nglayout.debug.disable_xul_cache", false); presenting in prefs.js → Mozilla crashes on startup with user_pref("nglayout.debug.disable_xul_cache", false); presenting in prefs.js
A couple of reports also in n.p.m.builds.

I get a crash on startup after choosing profile via dialogue box no matter
whether nglayout.debug.disable_xul_cache  is set to true or false. Deleting it
or starting  -P are workarounds.

RH 8.0, GTK2, Xft, gcc 3.2
 
Geoff
Depends on: 196446
Is this related to bug 196446 and/or bug 194834?   Should we mark it a dup?
I'm just going to mark this a dup of bug 196446.  If anyone thinks this is a
different crash, please feel free to reopen.
I checked in a patch that should fix these crashers (from bug 196446).  Please
reopen if they still happen starting with 3/12 builds.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 196970 has been marked as a duplicate of this bug. ***
I'm sorry but I need to reopen this bug report. I'm still having problems with
this patch. mozilla should be able to start with or without this pref present.
I'm using a 3/12 build and can't set/change this pref with QuickPrefsMenu
without crashing on windows NT4. This simple JS routine worked for two years
without a problem, but now it keeps mozilla crashing. 

FYI: QuickPrefsMenu is a mozilla/Phoenix extension and is also part of MultiZilla.

The crash is 100% reproducable for me and other MultiZilla users.

Workaround is to first enable the pref on the debug pref panel and then you can
change this pref setting in QPM but this workaround isn't 100% reliable.

Note: The Pref Toolbar (XUL Planet) could also be in trouble because it has a
button for it on its toolbar.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This problem is also reported by Bjarne Mathiesen (mozilla@mathiesen.info) using:
MacOS X 10.2.4 Jaguar ; Mozilla 1.4a ; PowerPC G4 800MHz 
Yes, I can reproduce this in Phoenix (but not Mozilla). I'll have to build
Phoenix to get a stack trace, if I get a chance. (I'm kinda wondering if this
is the same crash as before, or different).
Comment on attachment 117431 [details] [diff] [review]
additional patch to fix quickprefs crash

sr=me
Attachment #117431 - Flags: superreview+
Cool, thanks guys ;)

I changed the bug status from reopened to assigned, because closing as fixed bug
without being assigned first looks a bit weird, don't you think?
Status: REOPENED → ASSIGNED
checked in.  closing again.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
*** Bug 196992 has been marked as a duplicate of this bug. ***
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: