Closed Bug 295404 Opened 19 years ago Closed 19 years ago

Restoring default toolbar set causes crash - Trunk FF11a1 [@ 0x016b93d7 - nsGenericElement::QueryInterface] [@ 0xc340c033 - nsQueryInterface::operator]

Categories

(Firefox :: Toolbars and Customization, defect, P1)

Product:
Firefox
Component:
Toolbars and Customization
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox1.5

People

(Reporter: marcia, Assigned: dbaron)

References

(
URL
)

Details

(4 keywords, Whiteboard: [patch][eta 8/16][not blocking branch])

Crash Data

Attachments

(2 files)

crash log
2.00 KB, text/plain
Details
patch that fixes this crash
15.27 KB, patch
bzbarsky
: review+
bryner
: superreview+
asa
: approval1.8b4+
Details | Diff | Splinter Review 
Seen using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2)
Gecko/20050524 Firefox/1.0+

STR:

1.  Customize toolbar with a few icons. Click done.
2.  Go back into toolbar and click "Restore default set" and click done.

Confirm a crash shortly thereafter. You might have to type a new site in the URL
bar and do some other manipulation, but it crashes shortly thereafter. After
doing this you are also unable to customize the toolbar again, as that menu item
is greyed out.

Talkback submitted using yesterday's build (today's has no TB), will post TB ID
shortly.
Confirmed on WinXP using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b2) Gecko/20050524 Firefox/1.0+ ID:2005052413.

Followed the same steps, went back to a few sites and crash.  
per comment 1 -> All/All
Flags: blocking1.8b3?
Keywords: regression
OS: MacOS X → All
Hardware: Macintosh → All
so far hadn't been able to reproduce on Windows.  Traced the regression window
on Mac back to 2005-04-19-07-trunk Pass :: 2005-04-26-13-trunk Failed.  Is this
possibly related to the leak bug jst and bz are working on?    going to to try
to repro on a windows machine with less memory. Maybe that'll translate into a
faster crash.
OS: All → MacOS X
Hardware: All → Macintosh
I can reproduce this on linux fc3 (2005052410-trunk, deer park).
OS: MacOS X → All
Hardware: Macintosh → All
nominating.
Flags: blocking-aviary1.1?
My talkback ID is TB6099435X.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050523
Firefox/1.0+

Confirmed. 

1. Right click on toolbar, customise, .... change something ...., done.
2. Right click on toolbar (again), customise, restore default set, done.
3. Navigate to new page
4. FF crashes after tring to go back to previous page
my regression window tested on Mac was incorrect.  I wasn't waiting long enough
andor not navigating to another page to cause the crash.

I've regression tested this on Windows and discovered the window to be the
following:
Fx 2005-03-29-07-trunk works
Fx 2005-03-30-07-trunk crashes
from talkback incident #6106482:

firefox-bin + 0x85a15c (0x088a215c)
nsCOMPtr_base::assign_from_qi() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/xpcom/build/nsCOMPtr.cpp,
line 96]
nsXULDocument::AttributeChanged() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/content/xul/document/src/nsXULDocument.cpp,
line 1114]
nsXULElement::UnsetAttr() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 1751]
nsGenericElement::RemoveAttribute() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 146]
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2096]
XPC_WN_CallMethod() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1330]
js_Invoke() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/jsinterp.c,
line 1182]
js_Interpret() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/jsinterp.c,
line 3473]
js_Invoke() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/jsinterp.c,
line 1202]
nsXPCWrappedJSClass::CallMethod() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1339]
nsXPCWrappedJS::CallMethod() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 450]
PrepareAndDispatch() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp,
line 100]
nsBrowserStatusFilter::OnLocationChange() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/xpfe/browser/src/nsBrowserStatusFilter.cpp,
line 231]
nsDocLoader::FireOnLocationChange() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/uriloader/base/nsDocLoader.cpp,
line 848]
nsDocShell::CreateContentViewer() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 842]
nsDSURIContentListener::DoContent() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/docshell/base/nsDSURIContentListener.cpp,
line 131]
nsDocumentOpenInfo::TryContentListener() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/uriloader/base/nsURILoader.cpp,
line 739]
nsDocumentOpenInfo::DispatchContent() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/uriloader/base/nsURILoader.cpp,
line 842]
nsDocumentOpenInfo::OnStartRequest() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/uriloader/base/nsURILoader.cpp,
line 328]
nsHttpChannel::CallOnStartRequest() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,
line 697]
nsHttpChannel::ProcessNormal() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,
line 865]
nsHttpChannel::ProcessResponse() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,
line 800]
nsInputStreamPump::OnStateStart() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/netwerk/base/src/nsInputStreamPump.cpp,
line 385]
nsInputStreamPump::OnInputStreamReady() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/netwerk/base/src/nsInputStreamPump.cpp,
line 344]
nsInputStreamReadyEvent::EventHandler()
PL_HandleEvent() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/xpcom/threads/plevent.c,
line 699]
PL_ProcessPendingEvents() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/xpcom/threads/plevent.c,
line 633]
nsEventQueueImpl::ProcessPendingEvents() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/xpcom/threads/nsEventQueue.cpp,
line 421]
event_processor_callback() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/widget/src/gtk2/nsAppShell.cpp,
line 67]
libglib-2.0.so.0 + 0x479c7 (0x0030c9c7)
libglib-2.0.so.0 + 0x237bb (0x002e87bb)
libglib-2.0.so.0 + 0x25242 (0x002ea242)
libglib-2.0.so.0 + 0x254ef (0x002ea4ef)
libgtk-x11-2.0.so.0 + 0x10af97 (0x00818f97)
nsAppShell::Run() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/widget/src/gtk2/nsAppShell.cpp,
line 141]
nsAppStartup::Run() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 145]
XRE_main() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/toolkit/xre/nsAppRunner.cpp,
line 830]
main() 
[/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 62]
libc.so.6 + 0x14e23 (0x00b6ae23)
Based on that checkin range, and the stack, I'm guessing this might have been
caused by the checkin for bug 283129.
Severity: normal → critical
cc'ing dbaron, bz, and brendan who made or reviewed changes on the regression
date.  This is likely to become a pretty high profile cross platform crasher.
Can you all take a look and see if any of your checkins (approx bonsai window in
URL field) caused this? Thanks.
URL: http://bonsai.mozilla.org/cvsquery.cg...
So the place where we actually crash is:

1113                        nsCOMPtr<nsIContent> listener
1114                            = do_QueryInterface(bl->mListener);

in nsXULDocument.  bl is a BroadcastListener bl->mListener is:

344     nsIDOMElement*    mListener; // [WEAK] XXXwaterson crash waiting to happen!

So I'm guessing that the BroadcastListener outlived its mListener...
I was able to reproduce this with the latest Trunk build on Windows:
Incident ID: 6344264
Stack Signature	0x016b93d7 d541892d
Email Address	jay@mozilla.org
Product ID	FirefoxTrunk
Build ID	2005060216
Trigger Time	2005-06-02 17:55:21.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	
URL visited	bug 295404
User Comments	resetting toolbar to default and navigating to another site or
clicking on another tab.
Since Last Crash	571 sec
Total Uptime	571 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
0x016b93d7
nsGenericElement::QueryInterface 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 3260]
nsXULElement::QueryInterface 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 468]
nsXULDocument::AttributeChanged 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xul/document/src/nsXULDocument.cpp,
line 1117]
nsXULElement::SetAttrAndNotify 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 1564]
nsXULElement::SetAttr 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 1485]
nsGenericElement::SetAttribute 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 1402]
XPTC_InvokeByIndex 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2105]
XPC_WN_CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1348]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1178]
js_Interpret 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3469]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1198]
js_Interpret 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3469]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1198]
js_Interpret 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3469]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1198]
js_InternalInvoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1275]
JS_CallFunctionValue 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsapi.c, line 3858]
nsJSContext::CallEventHandler 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1386]
nsJSEventListener::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/events/nsJSEventListener.cpp,
line 184]
nsEventListenerManager::HandleEventSubType 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1568]
nsEventListenerManager::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1669]
nsXULElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2193]
nsXULElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2212]
nsEventStateManager::DispatchNewEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 4364]
nsEventListenerManager::DispatchEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 2002]
nsDOMEventRTTearoff::DispatchEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 651]
XPTC_InvokeByIndex 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2105]
XPC_WN_CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1348]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1178]
js_Interpret 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3469]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1198]
js_InternalInvoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1275]
js_InternalGetOrSet 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1318]
js_SetProperty 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2891]
js_Interpret 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3306]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1198]
js_InternalInvoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1275]
js_InternalGetOrSet 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1318]
js_SetProperty 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2891]
js_Interpret 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3306]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1198]
js_InternalInvoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1275]
js_InternalGetOrSet 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1318]
js_SetProperty 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2891]
js_Interpret 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3306]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1198]
js_InternalInvoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1275]
JS_CallFunctionValue 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsapi.c, line 3858]
nsJSContext::CallEventHandler 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1386]
nsJSEventListener::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/events/nsJSEventListener.cpp,
line 184]
nsXBLPrototypeHandler::ExecuteHandler 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xbl/src/nsXBLPrototypeHandler.cpp,
line 500]
nsXBLEventHandler::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xbl/src/nsXBLEventHandler.cpp,
line 85]
nsEventListenerManager::HandleEventSubType 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1568]
nsEventListenerManager::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1669]
nsXULElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2193]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6324]
PresShell::HandleEventWithTarget 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6229]
nsEventStateManager::CheckForAndDispatchClick 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 2924]
nsEventStateManager::PostHandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 1954]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6395]
PresShell::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6167]

Looks like this is going to show up under a number of different stack
signatures, so marking topcrash+ and adding a couple of signatures now.  Let's
see if we can get this fixed soon.
Keywords: topcrash+
Summary: Restoring default toolbar set causes crash → Restoring default toolbar set causes crash - Trunk FF11a1 [@ 0x016b93d7 - nsGenericElement::QueryInterface] [@ 0xc340c033 - nsQueryInterface::operator]
If nothing else, nsXULDocument::RemoveSubtreeFromDocument doesn't remove all the
relevant broadcast listeners (since RemoveBroadcastListener does an exact match
on the attr and doesn't treat "*" as meaning "remove all listeners).  Fixing
that doesn't help, though; I still crash.  Just have to open the toolbar
customization  dialog, click the "restore default" button, click "Done", type
"web.mit.edu" in the URL bar, and hit enter....
Vladimir, this is the toolbar crash bug that Marcia and I were talking about
earlier today.
*** Bug 299083 has been marked as a duplicate of this bug. ***
Cc'ing Josh Aas, as this is a mac topcrash and I /know/ he doesn't have enough
on his plate at the moment... ;)
Josh, can you take this.  Let's try and get this in for 1.1.
Assignee: nobody → joshmoz
Flags: blocking1.8b3?
Flags: blocking1.8b3+
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
I'm probably not going to figure this one out in time - recommending that
someone more familiar with this kind of bug take it for 1.8b3.
mconnor, can you have a look?
Has anyone caught this in a debugger? It appears that we're calling
QueryInterface on an object that is no longer, so we're either over-releasing
the object or we're holding a bad pointer. A tracerefcnt log might at least tell
us which option it is.
let's get this looked at and fixed for b4
Flags: blocking1.8b4+
Flags: blocking1.8b3-
Flags: blocking1.8b3+
Attached file crash log — 
My crash log, different from the other.

Sairuh, Jay - please don't paste huge crash logs into bug comments.
Josh: Are you still looking at this or does it need to be kicked over to someone
else? Just trying to see that it makes it to the right bucket.
Not able to reproduce on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.8b3) Gecko/20050712 Firefox/1.0+ ID:2005071206
someone else should take this (-> nobody@mozilla.org for now)
Assignee: joshmoz → nobody
Assignee: nobody → mconnor
Whiteboard: [needs investigation, might be fixed]
Yeah, it still exists, basically we're doing evil things that XBL can't handle,
per bz, so we'll have to band-aid this case, or kill the button.  The latter is
lower-risk.
Whiteboard: [needs investigation, might be fixed] → [eta 7/31]
WFM now (was 100% reproduceable here).

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050806
Firefox/1.0+
So this WFM using today's Firefox build - Mozilla/5.0 (Macintosh; U; PPC Mac OS
X Mach-O; en-US; rv:1.8b4) Gecko/20050808 Firefox/1.0+.

But I have been able to crash a late July Thunderbird build following the same
steps.  There is no mac tbird build today but I will test again to see if can
send some talkback.
Whiteboard: [eta 7/31] → [more investigation needed][eta 8/12][not blocking branch]
I just sent in Talkback for my crash on today's Thunderbird build - TB8222973K.
Using today's Firefox build - Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
en-US; rv:1.8b4) Gecko/20050809 Firefox/1.0+ - I crashed again.  Talkback ID
TB8227410G
Whiteboard: [more investigation needed][eta 8/12][not blocking branch] → [useful comments: 12, 14][more investigation needed][eta 8/12][not blocking branch]
Clarifying exact steps to repro:

1. Add a few icons to the toolbar using Customize. Click Done.
2. Go to Customize again and click "Restore Default Toolbar."

Shortly after this you will see all the menu items grayed out in both FF and
Thunderbird, and the "Customize" Option will be grayed out as well.  If you
click in the toolbar area enough times, that will trigger the crash.

(In reply to comment #0)
> Seen using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2)
> Gecko/20050524 Firefox/1.0+
> 
> STR:
> 
> 1.  Customize toolbar with a few icons. Click done.
> 2.  Go back into toolbar and click "Restore default set" and click done.
> 
> Confirm a crash shortly thereafter. You might have to type a new site in the URL
> bar and do some other manipulation, but it crashes shortly thereafter. After
> doing this you are also unable to customize the toolbar again, as that menu item
> is greyed out.
> 
> Talkback submitted using yesterday's build (today's has no TB), will post TB ID
> shortly.


On the basis of comment 12 and comment 14, I wrote this patch which fixes the
crash for me.

I'm still not sure what to do about dynamic attribute changes, though.	There's
code in nsXULElement::UnsetAttr that I didn't touch, but SetAttr is still a
problem, and it doesn't cover all the cases.
I guess my inclination is that we should probably:
 1. take the above patch
 2. make mListener a strong reference
 3. file additional bugs on the leaks that result from the attribute change cases

(Or, if there's a reason those leaks would lead to crashes, maybe skip (2).)

Thoughts?
Assignee: mconnor → dbaron
Flags: blocking-aviary1.5+
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [useful comments: 12, 14][more investigation needed][eta 8/12][not blocking branch] → [patch][useful comments: 12, 14][more investigation needed][eta 8/12][not blocking branch]
Target Milestone: --- → Firefox1.1
Attachment #192229 - Flags: superreview?(bryner)
Attachment #192229 - Flags: review?(bzbarsky)
Whiteboard: [patch][useful comments: 12, 14][more investigation needed][eta 8/12][not blocking branch] → [patch][useful comments: 12, 14][more investigation needed][eta 8/16][not blocking branch]
Whiteboard: [patch][useful comments: 12, 14][more investigation needed][eta 8/16][not blocking branch] → [patch][eta 8/16][not blocking branch]
Can you clarify exactly why this patch fixes the crash?  There's a lot of
cleanup and code-shuffling and I want to make sure I'm not missing the main
point.  Is it that |aElement| in RemoveSubtreeFromDocument becomes invalid after
the first call to RemoveBroadcastListenerFor in the existing code?  Or something
else?  I'm having a hard time connecting this patch to comment 12 without some
more explanation.

(In reply to comment #33)
> Created an attachment (id=192229) [edit]
> patch that fixes this crash
> 
> On the basis of comment 12 and comment 14, I wrote this patch which fixes the
> crash for me.
> 
> I'm still not sure what to do about dynamic attribute changes, though.	There's
> code in nsXULElement::UnsetAttr that I didn't touch, but SetAttr is still a
> problem, and it doesn't cover all the cases.
The main point is that it makes the removal code match what the addition code
does.  The change to CheckBroadcasterHookup is just refactoring -- splitting out
the FindBroadcaster part so that RemoveSubtreeFromDocument can use it.  The
intent is that ChangeBroadcasterHookup behave exactly as it currently does.
Attachment #192229 - Flags: superreview?(bryner) → superreview+
Flags: blocking1.8b5+
Comment on attachment 192229 [details] [diff] [review]
patch that fixes this crash

>Index: xul/document/src/nsXULDocument.h

>+    FindBroadcaster(nsIContent* aElement,
>+                    nsIDOMElement** aListener,
>+                    nsString& aBroadcasterID,
>+                    nsString& aAttribute,
>+                    nsIDOMElement** aBroadcaster);

Document what the return codes mean?  In particular which of the out params
will have meaningful values for which return code?  We have some codepaths in
this method that never set the aListener and aBroadcaster out params; maybe
init them to null up front?

r=bzbarsky with that done.
Attachment #192229 - Flags: review?(bzbarsky) → review+
Attachment #192229 - Flags: approval1.8b4?
It looks like bz checked this into the trunk last night, 2005-08-24 21:11 -0700.
Yeah, we wanted to get it into today's builds for baking before we
branchificated.  Should we mark it FIXED-for-trunk?
Yeah, fixed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
marcia, can you verify this? 
Verified using Mac Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.9a1) Gecko/20050826 Firefox/1.6a1. I can verify on Windows and Linux as well. 


There is a problem with the 8-26 trunk Windows build - reopening this bug.

If you add some icons to the toolbar and then go back and try to customize
again, suddenly that menu item is greyed out and you can't do anything.

There also appears to be an issue with the URL bar, which shows the favicon but
does not show the text of the site you are currently on. there may already be a
bug logged for that issue, I will check.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The URL bar location being empty is bug 306061.  The fix has been checked in.
Yeah, today's builds just had issues... Please recheck with tomorrow's builds?
Marking fixed again, since I haven't heard anyone say that the crash isn't fixed.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Verified on Windows using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9a1) Gecko/20050829 Firefox/1.6a1 as well as Mac 20050829/1.6a1. Tracy will
verify Linux.


Linux 2005-08-29-06-trunk is good as well.
Status: RESOLVED → VERIFIED
Attachment #192229 - Flags: approval1.8b4? → approval1.8b4+
Fix checked in to MOZILLA_1_8_BRANCH, 2005-08-29 12:56 -0700.
Keywords: fixed1.8
verified Firefox 1.4 (Win, Lin, Mac) builds from 2005-09-08
Keywords: fixed1.8 → verified1.8
Crash Signature: [@ 0x016b93d7 - nsGenericElement::QueryInterface] [@ 0xc340c033 - nsQueryInterface::operator]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: