Last Comment Bug 400735 - New startup crash [@ nsXBLBinding::AllowScripts]
: New startup crash [@ nsXBLBinding::AllowScripts]
Status: VERIFIED FIXED
: crash, fixed1.8.1.10, topcrash, verified1.8.1.9
Product: Core
Classification: Components
Component: XBL (show other bugs)
: 1.8 Branch
: x86 Windows XP
: -- critical (vote)
: ---
Assigned To: Jonas Sicking (:sicking) No longer reading bugmail consistently
:
: Andrew Overholt [:overholt]
Mentors:
http://talkback-public.mozilla.org/se...
Depends on: 373911
Blocks: 267833
  Show dependency treegraph
 
Reported: 2007-10-22 12:44 PDT by Samuel Sidler (old account; do not CC)
Modified: 2011-06-09 14:58 PDT (History)
28 users (show)
frenchfrog: blocking1.9?
mtschrep: blocking1.8.1.9+
dveditz: blocking1.8.1.10+
caillon: blocking1.8.0.next+
jwalden+bmo: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
iframe document, needed for testcase (531 bytes, application/vnd.mozilla.xul+xml)
2007-10-22 16:58 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details
testcase (390 bytes, text/html)
2007-10-22 16:59 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details
This might work (1.84 KB, patch)
2007-10-24 19:06 PDT, Jonas Sicking (:sicking) No longer reading bugmail consistently
bugs: review+
jst: superreview+
dveditz: approval1.8.1.9+
dveditz: approval1.8.1.10+
jonas: approvalM9+
jonas: approval1.9+
Details | Diff | Splinter Review

Description Samuel Sidler (old account; do not CC) 2007-10-22 12:44:35 PDT
A new topcrash has appeared in Firefox 2.0.0.8. It looks to be Windows-only and Dan says it's a result of the XBL rewrite.

Sample stack from Windows Vista (TB37237703):

Stack Signature	 nsXBLBinding::AllowScripts c18d9b85
Product ID	Firefox2
Build ID	2007100816
Trigger Time	2007-10-22 11:59:35.0
Platform	Win32
Operating System	Windows NT 6.0 build 6000
Module	firefox.exe + (0029bfd8)
URL visited	
User Comments	I am starting firefox under vista
Since Last Crash	1 sec
Total Uptime	33971 sec
Trigger Reason	Access violation
Source File, Line No.	c:/builds/tinderbox/Fx-Mozilla1.8-Release/WINNT_5.2_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp, line 1222
Stack Trace 	
nsXBLBinding::AllowScripts  [mozilla/content/xbl/src/nsXBLBinding.cpp, line 1222]
nsXBLBinding::ExecuteAttachedHandler  [mozilla/content/xbl/src/nsXBLBinding.cpp, line 794]
nsDocument::EndUpdate  [mozilla/content/base/src/nsDocument.cpp, line 2269]
mozAutoDocUpdate::~mozAutoDocUpdate  [../../../../dist/include/content/nsIDocument.h, line 938]
nsGenericElement::RemoveChildAt  [mozilla/content/base/src/nsGenericElement.cpp, line 2915]
nsXULElement::RemoveChildAt  [mozilla/content/xul/content/src/nsXULElement.cpp, line 1273]
nsContentOrDocument::RemoveChildAt  [mozilla/content/base/src/nsGenericElement.cpp, line 2968]
nsGenericElement::doReplaceOrInsertBefore  [mozilla/content/base/src/nsGenericElement.cpp, line 3618]
nsGenericElement::InsertBefore  [mozilla/content/base/src/nsGenericElement.cpp, line 3073]
XPCWrappedNative::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169]
XPC_WN_CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret  [mozilla/js/src/jsinterp.c, line 3946]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1394]
nsXPCWrappedJSClass::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453]
nsXPCWrappedJS::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
SharedStub  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
nsEventListenerManager::HandleEventSubType  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1655]
nsEventListenerManager::HandleEvent  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1762]
nsGlobalWindow::HandleDOMEvent  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 1733]
nsXULDocument::HandleDOMEvent  [mozilla/content/xul/document/src/nsXULDocument.cpp, line 1238]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2214]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleChromeEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2897]
nsGlobalWindow::HandleDOMEvent  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 1720]
DocumentViewerImpl::LoadComplete  [mozilla/layout/base/nsDocumentViewer.cpp, line 1014]
nsDocShell::EndPageLoad  [mozilla/docshell/base/nsDocShell.cpp, line 4822]
nsWebShell::EndPageLoad  [mozilla/docshell/base/nsWebShell.cpp, line 673]
nsDocShell::OnStateChange  [mozilla/docshell/base/nsDocShell.cpp, line 4737]
nsDocLoader::FireOnStateChange  [mozilla/uriloader/base/nsDocLoader.cpp, line 1210]
nsDocLoader::doStopDocumentLoad  [mozilla/uriloader/base/nsDocLoader.cpp, line 844]
nsDocLoader::OnStopRequest  [mozilla/uriloader/base/nsDocLoader.cpp, line 665]
nsLoadGroup::RemoveRequest  [mozilla/netwerk/base/src/nsLoadGroup.cpp, line 732]
nsDocument::UnblockOnload  [mozilla/content/base/src/nsDocument.cpp, line 5064]
nsBindingManager::ProcessAttachedQueueEvent::~ProcessAttachedQueueEvent  [mozilla/content/xbl/src/nsBindingManager.cpp, line 1411]
0x778b0c24
0x2df2e804
0x0e8b0000
0x74084139
0xc8835f06
0x8bc35eff
0x89480847
0x0d750847
0x5e5f168b
0x04245489
0x00064fe9
0xc0335f00
0x9090c35e
0x90909090
0x90909090
0x2dbae856
0x4c8b0000
0x518b0824
0x8b128b04
0xf03b0872
0x8b04755e
0x33c30841


Sample stack from Windows XP (TB37236972):

Stack Signature	 nsXBLBinding::AllowScripts 8027da8c
Product ID	Firefox2
Build ID	2007100816
Trigger Time	2007-10-22 11:41:34.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (0029bfd8)
URL visited	
User Comments	
Since Last Crash	4 sec
Total Uptime	11706 sec
Trigger Reason	Access violation
Source File, Line No.	c:/builds/tinderbox/Fx-Mozilla1.8-Release/WINNT_5.2_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp, line 1222
Stack Trace 	
nsXBLBinding::AllowScripts  [mozilla/content/xbl/src/nsXBLBinding.cpp, line 1222]
nsXBLBinding::ExecuteAttachedHandler  [mozilla/content/xbl/src/nsXBLBinding.cpp, line 794]
nsDocument::EndUpdate  [mozilla/content/base/src/nsDocument.cpp, line 2269]
mozAutoDocUpdate::~mozAutoDocUpdate  [../../../../dist/include/content/nsIDocument.h, line 938]
nsGenericElement::RemoveChildAt  [mozilla/content/base/src/nsGenericElement.cpp, line 2915]
nsXULElement::RemoveChildAt  [mozilla/content/xul/content/src/nsXULElement.cpp, line 1273]
nsContentOrDocument::RemoveChildAt  [mozilla/content/base/src/nsGenericElement.cpp, line 2968]
nsGenericElement::doReplaceOrInsertBefore  [mozilla/content/base/src/nsGenericElement.cpp, line 3618]
nsGenericElement::InsertBefore  [mozilla/content/base/src/nsGenericElement.cpp, line 3073]
XPCWrappedNative::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169]
XPC_WN_CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret  [mozilla/js/src/jsinterp.c, line 3946]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1394]
nsXPCWrappedJSClass::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453]
nsXPCWrappedJS::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
SharedStub  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
nsEventListenerManager::HandleEventSubType  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1655]
nsEventListenerManager::HandleEvent  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1762]
nsGlobalWindow::HandleDOMEvent  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 1733]
nsXULDocument::HandleDOMEvent  [mozilla/content/xul/document/src/nsXULDocument.cpp, line 1238]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2214]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleChromeEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2897]
nsGlobalWindow::HandleDOMEvent  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 1720]
DocumentViewerImpl::LoadComplete  [mozilla/layout/base/nsDocumentViewer.cpp, line 1014]
nsDocShell::EndPageLoad  [mozilla/docshell/base/nsDocShell.cpp, line 4822]
nsWebShell::EndPageLoad  [mozilla/docshell/base/nsWebShell.cpp, line 673]
nsDocShell::OnStateChange  [mozilla/docshell/base/nsDocShell.cpp, line 4737]
nsDocLoader::FireOnStateChange  [mozilla/uriloader/base/nsDocLoader.cpp, line 1210]
nsDocLoader::doStopDocumentLoad  [mozilla/uriloader/base/nsDocLoader.cpp, line 844]
nsDocLoader::OnStopRequest  [mozilla/uriloader/base/nsDocLoader.cpp, line 665]
nsLoadGroup::RemoveRequest  [mozilla/netwerk/base/src/nsLoadGroup.cpp, line 732]
nsDocument::UnblockOnload  [mozilla/content/base/src/nsDocument.cpp, line 5064]
nsBindingManager::ProcessAttachedQueueEvent::~ProcessAttachedQueueEvent  [mozilla/content/xbl/src/nsBindingManager.cpp, line 1411]
0x778b0c24
nsSVGTextFrame::nsSVGTextFrame  [mozilla/layout/svg/base/src/nsSVGTextFrame.cpp, line 233]
0x029a0292
0x00340000
Comment 1 Samuel Sidler (old account; do not CC) 2007-10-22 12:56:05 PDT
Most of the comments seem to indicate that this crash is happening on startup. Adding that to the summary.

This is probably related to an extension (Flashblock maybe?).

Sample comments:
  * I started firefox and there was a fail error
  * opened firefox 
  * crashed after clicking start bar icon to start open browser
  * Opening after installing the latest update
  * clicked from a link in email then this came up has only happened since 
    updating firefox to f.f 8
  * when starting up, fails to start
  * Attempted to start it... just upgraded Firefox last night
Comment 2 Mike Schroepfer 2007-10-22 14:54:04 PDT
Jonas - can you take a look here?
Comment 3 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-22 15:19:57 PDT
I'll look at this, but it would be a huge help if someone could come up with steps to reproduce.
Comment 4 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-10-22 15:23:56 PDT
Fwiw, bug 292717 seemed to have a testcase that crashed with a similar stack as this one.
Comment 8 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-10-22 16:58:25 PDT
Created attachment 285803 [details]
iframe document, needed for testcase

Ok, I think I managed to get a testcase that crashes with this stack trace on branch. The testcase that I'll attach should crash within 500ms.
Comment 9 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-10-22 16:59:05 PDT
Created attachment 285804 [details]
testcase
Comment 10 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-10-22 17:24:58 PDT
This seems to have been fixed on trunk (regarding the testcase) between 2007-08-21 and 2007-08-22:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-08-21+11&maxdate=2007-08-22+09&cvsroot=%2Fcvsroot
I guess fixed by bug 373911.
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2007-10-22 19:17:55 PDT
Hmm.  I wonder whether we're hitting EM restart weirdness here or something.  smaug, can we port bug 373911 to branch without too much pain?
Comment 12 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-23 17:32:57 PDT
Martijn: I'm unable to crash with any of the attached testcases. Do I need to run them in any particular way? What platform are you on?
Comment 13 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-10-23 17:36:47 PDT
I'm on windowsXP. The testcase should just crash on load.
Did you try out the testcases in bug 373911, they are basically the same, more or less.
Comment 14 Olli Pettay [:smaug] 2007-10-24 01:25:09 PDT
Checked in patch for Bug 373911, attachment 285804 [details] doesn't crash for me anymore.
Comment 15 Daniel Veditz [:dveditz] 2007-10-24 07:18:05 PDT
Marking fixed in hopes that the crash we know about is in fact the crash users are suffering from. Won't know for sure until after we ship, unfortunately.
Comment 16 Carsten Book [:Tomcat] 2007-10-24 07:43:20 PDT
no crash for me with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.9pre) Gecko/2007102404 BonEcho/2.0.0.9pre after tests with the  testcase from this Bug.

-> Adding verified keyword
Comment 17 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-24 11:42:52 PDT
What are these testcases based on? Bug 373911 is all about xbl destructors, but the stack here shows us crashing while in xbl constructors.
Comment 18 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-24 11:44:00 PDT
The fact that both crash in nsXBLBinding::AllowScripts I suspect is because both call functions on deleted nxXBLBindings.
Comment 19 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-24 11:51:49 PDT
I don't think these testcases are about this bug at all. Is anyone really crashing with nsXBLBinding::ExecuteAttachedHandler on the stack
Comment 20 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-24 11:55:10 PDT
Removing fixed-keywords
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2007-10-24 12:49:02 PDT
So...  Looking at the stacks, we're crashing because the binding's mBoundElement is somehow busted (has a non-null bogus GetOwnerDoc()), right?  At least if the line number can be trusted?

That does make it likely that we're talking deleted bindings.  The question is how.  The binding manager holds a strong ref to its bindings, right?  The event is holding a strong ref to the binding manager... then again we're really running constructors for a document different from the one that posted the event, I think.

I'd love to have an idea of what's calling nsBindingManager::ProcessAttachedQueueEvent::~ProcessAttachedQueueEvent.  The stacks in this bug seem to be bogus-ish down there.
Comment 22 Olli Pettay [:smaug] 2007-10-24 15:24:25 PDT
Just something I noticed while reading the code (may not cause the problem);
should ~ProcessAttachedQueueEvent keep strong pointer to the document when 
calling UnblockOnload()? Document owns bindingmanager, but bm has only raw
pointer back to document.
Comment 23 Boris Zbarsky [:bz] (still a bit busy) 2007-10-24 15:38:08 PDT
Hmm.  That's probably a good idea, yes.
Comment 24 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-24 15:46:33 PDT
Another thing that is weird here is that nsGenericElement::RemoveChildAt ends up executing XBL ctors. All we should have done between its BeginUpdate and EndUpdate is removing elements which should not add to the queue. Additionally, there is an mozAutoDocUpdate living higher up on the stack in nsGenericElement::doReplaceOrInsertBefore, so we should still be waiting for the last EndUpdate and not even looking at xbl.

I wonder if it simply is the document dying from the missing strong reference after all...
Comment 25 Boris Zbarsky [:bz] (still a bit busy) 2007-10-24 15:56:55 PDT
> is removing elements which should not add to the queue.

Removing elements can trigger frame reconstructs (e.g. with {ib} splits), which could in fact run XBL ctors...  Now that sort of thing _shouldn't_ be happening in our UI, I would hope.

> there is an mozAutoDocUpdate living higher up on the stack in
> nsGenericElement::doReplaceOrInsertBefore

It's only a real update batch if we're replacing or if we're inserting a document fragment.
Comment 26 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-24 16:27:01 PDT
(In reply to comment #25)
> > is removing elements which should not add to the queue.
> 
> Removing elements can trigger frame reconstructs (e.g. with {ib} splits), 
> which could in fact run XBL ctors...  Now that sort of thing _shouldn't_ be 
> happening in our UI, I would hope.

That shouldn't add new bindings to the attached-stack though, would it? Though I guess in theory any sort of new style rules could kick in and attach new bindings.

However it seems unlikely that that is what's happening here.

> > there is an mozAutoDocUpdate living higher up on the stack in
> > nsGenericElement::doReplaceOrInsertBefore
> 
> It's only a real update batch if we're replacing or if we're inserting a
> document fragment.

Doh! Very true. That explains some of the weirdness I thought was there.
Comment 27 Daniel Fladmose 2007-10-24 16:52:25 PDT
Hi

I don't know, if I can help. But I received an email from Mozilla Security concerning this crash, asking me, if I had any add-ons installed.

And yes, I have. This crash started, after I had installed a theme called Modern Aluminum and Nasa Night Launch. I had also installed some Dictionaries. After this, it started to crash at start up. Oh yes, and I had asked Firefox to, every time it opens, show my last screen. 

Now I set it to default, so it shows my homepage at start up - this has stopped the crashes. 

Please tell if information like this can help - so I know, if I should tell another time.

Regards

Daniel, 

Denmark
Comment 28 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-24 19:06:12 PDT
Created attachment 286107 [details] [diff] [review]
This might work

I found one bug that might be the cause of this. When we're adding bindings to the mAttachedStack in order to execute their ctor we add binding->GetFirstBindingWithConstructor, however when removing, we try to remove the binding itself. This means that if:

1. A binding is attached to the element
2. The binding doesn't have a constructor, but one of its inherited bindings do
and
3. The element looses the binding (and is potentially destroyed) before we
   execute the constructor

We will execute the constructor when we shouldn't, potentially after the element has gone away.

I also added the strong reference while calling doc->UnblockOnload just in case.

While reviewing, plase add any concerns about potential regressions since this will get very little testing. I can't think of any risks here though.

(marking testcases obsolete since they don't apply to this bug)
Comment 29 Boris Zbarsky [:bz] (still a bit busy) 2007-10-24 20:26:03 PDT
Do we need a similar change on trunk?  Or not with your change to implementation installation?
Comment 30 John Demmers 2007-10-24 22:18:24 PDT
I've installed:

Themes:
Aluminium Kai
Nasa Nigth Launch
Red Shift V2

Add-ons
Adblock
Bookmark Dublicate Detector
Cookiesafe
Del.icio.us bookmarks
DOM inspector
Downloadhelper
DownThemAll
FastVideoDownload
FasterFox
Flashgot
Gmail Manager
Google Browse Sync
Google Calendar Notifier
Google Calender Quick Add
Google Video Downloader
IE TAB
NoScript
OpenTaalWoordenlijst
Talkback
United States English Dictionary
VideoDownloader
Woordenboek Nederlands

Comment 31 Johnny Stenback (:jst, jst@mozilla.com) 2007-10-24 23:20:07 PDT
Comment on attachment 286107 [details] [diff] [review]
This might work

sr=jst
Comment 32 Johnny Stenback (:jst, jst@mozilla.com) 2007-10-24 23:22:16 PDT
(In reply to comment #27)
[...]
> Please tell if information like this can help - so I know, if I should tell
> another time.

Hello Daniel,

Yes, this kind of information is helpful in general. The more details the better generally. Thank you.
Comment 33 Daniel Veditz [:dveditz] 2007-10-25 00:01:21 PDT
Comment on attachment 286107 [details] [diff] [review]
This might work

approved for 1.8.1.9/1.8.1.10 pending r+ from Smaug, a=dveditz

Please land on GECKO181_200710004_RELBRANCH for 1.8.1.9, the regular 1.8 branch for 1.8.1.10
Comment 34 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-25 00:22:18 PDT
Olli, feel free to only land on the 1.8.1.9 minibranch, i can take care of the other branches if you'd like.

Boris: As things stand now we do need to land on trunk. But my installimplementation patch would fix it too.
Comment 35 Olli Pettay [:smaug] 2007-10-25 02:39:23 PDT
Comment on attachment 286107 [details] [diff] [review]
This might work

Ugh, nsIXBLService::LoadBindings' out param is misleading.
Comment 36 Olli Pettay [:smaug] 2007-10-25 02:54:14 PDT
Checked in to GECKO181_20071004_RELBRANCH (that is the right branch, not GECKO181_200710004_RELBRANCH, right?) and MOZILLA_1_8_BRANCH.
Setting fixed1.8.1.9, fixed1.8.1.10, but some verification is needed.
Comment 37 Carsten Book [:Tomcat] 2007-10-25 06:28:32 PDT
Daniel, John (and whoever crashs with this talkback crash signature): Can you try the latest Nightly 1.8 Windows Build (the firefox-2.0.0.9pre.en-US.win32.installer.exe) from: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/
if you still crash ? In this build the patch form this bug is included.

Thanks ! :-)
Comment 38 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-10-25 06:32:24 PDT
John already tried out the latest 1.8 branch build, this is what he replied to me:
"
Hi, Martijn - I installed firefox-2.0.0.9pre.en-US.win32.installer.exe from
the link below, and it installed Bon Echo version 2.0.0.9pre.  I have
completely exited, verified that firefox.exe was no longer loaded, and
restarted, BE more than 10 times without any startup problems.

I just tried running Firefox, and it crashed upon startup (I *did* send the
error report and referenced this bug #)

Looks like the patch might have fixed the startup problem.

I'll run with Bon Echo today - hopefully it's stable enough.  I'll continue
to try Firefox every now and then until the next update comes down.
"

So it seems that it fixes the startup crash for John (fingers crossed).
I'm not completely sure he tested with today's 1.8 build or yesterday's 1.8 build, though.
Comment 39 Daniel Fladmose 2007-10-25 07:08:43 PDT
(In reply to comment #37)
> Daniel, John (and whoever crashs with this talkback crash signature): Can you
> try the latest Nightly 1.8 Windows Build (the
> firefox-2.0.0.9pre.en-US.win32.installer.exe) from:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/
> if you still crash ? In this build the patch form this bug is included.
> 
> Thanks ! :-)
> 

I'll try it right away.
Comment 40 Daniel Fladmose 2007-10-25 07:50:21 PDT
I have installed now. What is this Bon Echo? :)

It didnt crash EVERY time, I started Firefox, so I dont know, if it has helped anything yet.
Comment 41 Daniel Veditz [:dveditz] 2007-10-25 10:13:27 PDT
"Bon Echo" is the code name for pre-release/testing versions of Firefox 2. We change the in-product branding so people know they don't have an official release version (particularly handy for active testers who switch back and forth -- sometimes you can forget which one you're using).

When Firefox 2.0.0.9 is released please switch back to branded versions of Firefox.
Comment 42 Daniel Fladmose 2007-10-25 10:23:20 PDT
Thank you, Daniel :)

It may be a stupid question, but how do I switch back, and will I be noticed, when the new is released?

Comment 43 Daniel Veditz [:dveditz] 2007-10-25 11:49:09 PDT
Since this is branch-only it can be marked FIXED over-all
Comment 44 Boris Zbarsky [:bz] (still a bit busy) 2007-10-25 12:38:41 PDT
The crash may be, but the underlying bug is not.  See comment 34...
Comment 45 Daniel Veditz [:dveditz] 2007-10-25 13:35:24 PDT
(In reply to comment #42)
> how do I switch back, and will I be noticed, when the new is released?

If you stick with "Bon Echo" you will get a new test build every day. Unless you're a tester you will probably find this annoying.

To switch back, install any version of Firefox 2 and it will upgrade when the new release is available. If you've installed them in separate directories (which is the default) you probably still have Firefox 2.0.0.8 and can just start using it again.
Comment 46 Daniel Fladmose 2007-10-25 13:37:35 PDT
Ah, great :)

Who ever you are, you are some pretty amazing programmers.
Comment 47 Daniel Fladmose 2007-10-25 13:46:07 PDT
I have switched back, and the bug is still there. I am just gonna wait for a Firefox-update. Again, I solved the problem by choosing " Show Homepage at start-up".
Comment 48 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-25 15:18:51 PDT
Comment on attachment 286107 [details] [diff] [review]
This might work

Would be great to get this on trunk too, just to get more testing on it.
Comment 49 Mike Beltzner [:beltzner, not reading bugmail] 2007-10-26 12:19:07 PDT
Comment on attachment 286107 [details] [diff] [review]
This might work

a=endgame drivers for M9
Comment 50 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-26 20:25:54 PDT
Marking this FIXED as the patch in bug 345711 happens to fix this one as well. So the patch never ended up landing on trunk as it's not needed any more.
Comment 51 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-26 20:28:27 PDT
Comment on attachment 286107 [details] [diff] [review]
This might work

Resetting flags as this is no longer needed.
Comment 52 Boris Zbarsky [:bz] (still a bit busy) 2007-10-26 20:57:27 PDT
We don't need the strong ref to document on trunk?
Comment 53 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-26 21:54:49 PDT
Doh!
Comment 54 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-26 21:55:34 PDT
Comment on attachment 286107 [details] [diff] [review]
This might work

Putting back flags i errorously reset.
Comment 55 François Gagné 2007-10-27 08:41:08 PDT
My Bad :(

patch already have:
approval1.9+
approvalM9+
Comment 56 Tony Mechelynck [:tonymec] 2007-10-27 15:21:17 PDT
(In reply to comment #45)
> (In reply to comment #42)
> > how do I switch back, and will I be noticed, when the new is released?
> 
> If you stick with "Bon Echo" you will get a new test build every day. Unless
> you're a tester you will probably find this annoying.
> 
> To switch back, install any version of Firefox 2 and it will upgrade when the
> new release is available. If you've installed them in separate directories
> (which is the default) you probably still have Firefox 2.0.0.8 and can just
> start using it again.
> 

To have BonEcho warn you when a new release of Firefox is available (and not install a new version every day), install the "Update Channel Selector" extension and select the "Release" channel from that extension's preferences. (Note: setting it by hand in about:config , prefs.js or user.js doesn't work. Don't ask me why.) Also, you might want to select "Ask me what I want to do" under Tools => Options => Advanced => Update.
Comment 57 Daniel Fladmose 2007-10-27 16:02:35 PDT
Thanks.
Comment 58 Nick Thomas [:nthomas] 2007-10-28 05:17:54 PDT
(In reply to comment #56)
> To have BonEcho warn you when a new release of Firefox is available (and not
> install a new version every day), install the "Update Channel Selector"
> extension and select the "Release" channel from that extension's preferences.
> (Note: setting it by hand in about:config , prefs.js or user.js doesn't work.
> Don't ask me why.) Also, you might want to select "Ask me what I want to do"
> under Tools => Options => Advanced => Update.

Tony, you're saying something different to comment #45. The nightly channel is the odd-one-out, working differently from all others (release etc).
 * on nightly, you're always offered the most recent nightly build from the same branch, regardless of the particular build you're using now
 * on release, only specific builds are offered the latest release

So if you have some Bon Echo build on nightly, and you switch to release, then you won't get any updates (as the nightly buildID and version don't match any prior releases). That's why dveditz suggested installing a release version of Firefox 2.
Comment 59 Tony Mechelynck [:tonymec] 2007-10-28 06:44:01 PDT
(In reply to comment #58)
[...]
> So if you have some Bon Echo build on nightly, and you switch to release, then
> you won't get any updates (as the nightly buildID and version don't match any
> prior releases). That's why dveditz suggested installing a release version of
> Firefox 2.
> 

ah, sorry, I thought it would work. OTOH installing a release version of Fx2 (built before the patch landed, there aren't any others yet) as suggested in comment #45, certainly wouldn't cure the crash. Unless you keep that Fx2 release build on somme innocuous page (such as about: ) and do _not_ browse with it (browse with BonEcho instead), but use it _only_ to watch for updates.
Comment 60 pal-moz 2007-10-29 16:46:12 PDT
is this fixed on 2.0.0.9 (RC1) ?
Comment 61 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-10-29 17:03:00 PDT
(In reply to comment #60)
> is this fixed on 2.0.0.9 (RC1) ?

It should be. Please test that it does!
Comment 62 pal-moz 2007-10-29 17:34:29 PDT
(In reply to comment #61)
> (In reply to comment #60)
> > is this fixed on 2.0.0.9 (RC1) ?
> 
> It should be. Please test that it does!
> 

no startup-crash both 2.0.0.8 and 2.0.0.9(RC) for me.

but this is not marked as "fixed", marked as "reopened"
why? what for ?
not completely fixed yet ?
Comment 63 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-10-29 19:24:40 PDT
Checked in the remaining parts to trunk.

pal-moz, the fixedx.x.x.x keywords are used to track branch status of a bug. We only mark it FIXED once it's fixed on trunk, which this wasn't.
Comment 64 pal-moz 2007-10-29 19:49:25 PDT
(In reply to comment #63)
> Checked in the remaining parts to trunk.
> 
> pal-moz, the fixedx.x.x.x keywords are used to track branch status of a bug. We
> only mark it FIXED once it's fixed on trunk, which this wasn't.
> 

OK, understood. thanks.
Comment 65 Daniel Veditz [:dveditz] 2007-10-31 11:36:42 PDT
The incoming crash data on the 2.0.0.9 release candidate does not show any crashes at this location, but given the total number of crashes we'd only expect one or two reports so there are not yet enough data to be conclusive. Anecdotally half a dozen people who were regularly experiencing this crash in 2.0.0.8 have reported that 2.0.0.9 fixes the problem, and none report that it does not (but that's out of 150 or so mails sent out so not a great response rate).
Comment 66 john ruskin 2007-11-02 16:22:34 PDT
An anecdotal comment.   This bug fix, it seems, has eliminated a persistent and annoying history of crashes [with and without talkback sessions] with the recent versions of 2.--x.

These crashes, or more accurately, the propensity of crashes while operating [not just on startup] seems to come and go in waves.  There have been 3 or 4 episodes of this that I remember over the course of versions 1.5.x and into 2.009.  They waves start up with an update, and persist, and then disappear, with some subsequent update.

I mention this, as I wonder if there is some meta process that could be changed that might minimize the appearance of these unexplained crashes, until someone identifies a particular bug that, for all intensive purpose, is unknown to the users, and where the crashes have been unsolvable.

Would the meta changes be a shift in the attention to assumptions made by various routines in the mass of code which is Fox?   Is there a global search/pattern that could be undertaken that would flush out potential future problems?   Are the [if there is even one assumption...] routines' assumptions not fully documented in some way, so that users of called routines, see the assumptions, and might be more likely to encode and anticipate?   Does the existence of these assumptions, or the non documentation or non awareness...  could this be an artifact of the way, particularly, the Fox software is organized [ as opposed to the nature of the collaborative programming that is Moz and Fox, generally?]

I mention these ideas, because I am superbly and genuinely appreciative of the dedicated and professional [and even hobby] programmers who contribute to Moz/Fox/etc., but also tested by the crashes which run amok and unexplained.

Consequently, I wonder if adjustments to the process, or something, might lessen the chances of error.  I realize there is no quick fix, coming from initiating these thoughts; but felt that they would be useful, in addition to providing an anecdotal addition to this fixes comments. 

--bs/ms engr., jd 
Comment 67 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-11-03 00:45:23 PDT
If the crashes have disappeared they probably were due to this bug and are now fixed. So all is well, no?
Comment 68 Daniel Veditz [:dveditz] 2007-11-04 13:37:01 PST
Absolutely no sign of nsXBLBinding::AllowScripts crashes in FF2.0.0.9 talkback reports. Unlike my tentative report in comment 65 we now have a definitive amount of feedback and can confidently put this one to rest.
Comment 69 Mike Schroepfer 2007-11-08 15:45:44 PST
That is fantastic. Well done everyone!
Comment 70 Al Billings [:abillings] 2007-11-15 16:44:46 PST
Marking "verified1.8.1.10" as this was already "verified1.8.1.9" and we haven't touched this since 1.8.1.9.
Comment 71 Daniel Veditz [:dveditz] 2007-11-15 17:38:07 PST
Since there's no reproducible testcase we didn't verify 1.8.1.9 until we got crash-data back. 1.8.1.10 shipped from a different branch, and no matter how small the chance, there might have been a screw-up landing it. We can't really claim verified just because it worked on a different branch. A CVS diff of the two branches might suffice, but I'd be happier waiting for beta crash-data.
Comment 72 Al Billings [:abillings] 2007-11-15 17:49:43 PST
I didn't realize that we'd landed it separately. You're right.
Comment 73 Alexander Sack 2008-02-28 07:57:56 PST
we should verify what to do on 1.8.0 after bug 373911 landed.

Note You need to log in before you can comment on or make changes to this bug.