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

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Arkady Sherman]

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:  
:)

Comment 1

[Boris Zbarsky [:bzbarsky]]

Not preferences...

Comment 2

[John Morrison]

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

Comment 3

[John Morrison]

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., ...

Comment 4

[Geoff Leach]

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

Comment 5

[Jay Patel [:jay]]

Is this related to bug 196446 and/or bug 194834?   Should we mark it a dup?

Comment 6

[Jay Patel [:jay]]

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.

Comment 7

[Brian Ryner (not reading)]

I checked in a patch that should fix these crashers (from bug 196446).  Please
reopen if they still happen starting with 3/12 builds.

Comment 8

[Nicholas Allen]

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

Comment 9

[HJ]

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.

Comment 10

[HJ]

This problem is also reported by Bjarne Mathiesen ([e-mail]) using:
MacOS X 10.2.4 Jaguar ; Mozilla 1.4a ; PowerPC G4 800MHz 

Comment 11

[John Morrison]

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 12

[Brian Ryner (not reading)]

Attachment: additional patch to fix quickprefs crash

Comment 13

[Joe Hewitt (gone)]

Comment on attachment 117431 [details] [diff] [review]
additional patch to fix quickprefs crash

sr=me

Comment 14

[HJ]

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?

Comment 15

[Brian Ryner (not reading)]

checked in.  closing again.

Comment 16

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 117431 [details] [diff] [review]
additional patch to fix quickprefs crash

sr=[e-mail]

Comment 17

[Mike Kaply [:mkaply]]

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