User Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0a1) Gecko/20110811 Firefox/8.0a1
Build ID: 20110811152156
Steps to reproduce:
1. Downloaded https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1313101316/firefox-8.0a1.en-US.win32.zip
2. Extract and ran firefox -P with new profile
3. Installed http://www.echofon.com/twitter/firefox/Echofon.xpi and restart
4. Right click on Echofon toolbar, preferences, advanced, check Use SSL for all requests (This is important), and authorize Echofon
5. when authroized, firefox crash
Note: firefox won't crash if uncheck "Use SSL for all requests".
Crash [@ xul.dll@0x9cd449 ]
0 xul.dll xul.dll@0x9cd449
1 xul.dll xul.dll@0x9d830c
2 ssl3.dll ssl3.dll@0x6d4f
3 ssl3.dll ssl3.dll@0x9563
4 ssl3.dll ssl3.dll@0x96cd
5 ssl3.dll ssl3.dll@0x9b79
6 ssl3.dll ssl3.dll@0x9eb5
7 ssl3.dll ssl3.dll@0xb022
8 ssl3.dll ssl3.dll@0xfb0d
9 ssl3.dll ssl3.dll@0x10920
10 ssl3.dll ssl3.dll@0x109ad
11 ssl3.dll ssl3.dll@0x135f9
12 xul.dll xul.dll@0x42f545
13 nspr4.dll nspr4.dll@0x220f
14 nspr4.dll nspr4.dll@0x1d2c
15 mozcrt19.dll mozcrt19.dll@0x2c27
16 mozcrt19.dll mozcrt19.dll@0xd297
17 mozcrt19.dll mozcrt19.dll@0x2cb5
18 kernel32.dll BaseThreadInitThunk
19 ntdll.dll __RtlUserThreadStart
20 kernel32.dll WerpReportFaultInternal
21 kernel32.dll WerpReportFaultInternal
Bad http://hg.mozilla.org/mozilla-central/rev/10915aa17365 Mounir Lamouri — Merging mozilla-inbound into mozilla-central.
Confirmed on nightly Nightly linux build.
Mozilla/5.0 (X11; Linux i686; rv:8.0a1) Gecko/20110812 Firefox/8.0a1 ID:20110812030744
And also crashes on
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110812 Firefox/8.0a1 ID:20110812030744
be91fb29d950 Luke Wagner — Bug 674597 - abort if attempting to create an xpcom proxy for wrapped JS (r=bsmedberg)
Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110812 Firefox/8.0a1 ID:20110812030744
Well, it looks like we have a binary component attempting to create an xpcom proxy for wrapped JS. This is an invalid/unsafe operation.
To be clear: that's all bug 674597 does; check and abort.
Can reproduce, the offending NS_GetProxyForObject is http://hg.mozilla.org/mozilla-central/file/cec797d85529/security/manager/ssl/src/nsNSSIOLayer.cpp#l394; Echofon must be implementing a nsIDocShellTreeItem.
Created attachment 552804 [details] [diff] [review]
This fixes the assert for me. I just did a simple conversion to runnable like bug 674571.
Kai: before bug 674597 and with this patch, the "rootItem do_QI is null" assert fires (this is with Echofon installed); can I remove it?
Comment on attachment 552804 [details] [diff] [review]
Created attachment 552822 [details] [diff] [review]
Kai, there was a peculiar thing (we think a bug) where NS_ProxyRelease was being called in secureUI right before secureUI was used again. I just wanted to call your attention to this so you could double check.
Luke, I found another problem similar to this in the same code path: we will sometimes try to create an XPCOM proxy for an nsIPrompt that is implemented by JS. I am working on a fix that this, that, and at least one other related bug with a single runnable. I would rather use that solution than this one.
Brian, thanks a lot for your help on this. I have two patches converting two more sites where proxies are used into runnables (bug 678440 and bug 678547), one of which is an nsIPrompt, so hopefully this helps. I'm now actively investigating this bug.
Oops, I have my bugs confused; this is bug 678440 and I am investigating bug 678706. But bug 678547 does have the nsIPrompt patch.
EnsureDocShellDependentStuffKnown is called (through GetPreviousCert) on the critical path of certificate chain validation in the SSL handshake. AFAICT, adding a sync dispatch to it will cause certificate path validation--and all network I/O--to wait for the main thread's event queue to drain. I do not know how much of a performance impact that would have but I think I have an alternative solution with better performance characteristics. Will post soon.
IIUC, this wouldn't be *adding* a sync dispatch, but replacing the (slower) one inherent in proxies. Actually, this patch replaces three proxy dispatches (each doing a round-trip sync). You know the code better so I'm happy to let you do the patch though.
Created attachment 553609 [details] [diff] [review]
bsmith has some patches to kill most proxies in ssl (bsmedberg also has a patch under review to remove *all* xpcom/proxies). However, neither of these will be landing in the next day or two, so bsmith and I agreed to just back out the offending patch and dependent asserts. This is just a backout, so no r=, just approval to land on just-branched aurora.
Comment on attachment 553609 [details] [diff] [review]
Approved for mozilla-aurora
Crashes have dropped to 0, marking fixed.
*** Bug 678547 has been marked as a duplicate of this bug. ***
*** Bug 678987 has been marked as a duplicate of this bug. ***
*** Bug 678706 has been marked as a duplicate of this bug. ***
*** Bug 678710 has been marked as a duplicate of this bug. ***
Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101 Firefox/8.0
I tried to install the plugin from the link in bug description but plugin can not be installed because it is incompatible with Firefox 8.0. Is there another version of plugin that is compatible with Firefox 8?
Mihaela, I notice that Echofon 2.2.4 beta 1 compatible with Firefox 8 http://www.echofon.com/twitter/firefox/Echofon_beta.xpi
*** Bug 679035 has been marked as a duplicate of this bug. ***
*** Bug 679030 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows NT 5.1; rv:10.0a1) Gecko/20111006 Firefox/10.0a1
Mozilla/5.0 (X11; Linux i686; rv:10.0a1) Gecko/20111006 Firefox/10.0a1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a1) Gecko/20111006 Firefox/10.0a1
Mozilla/5.0 (Windows NT 6.1; rv:10.0a1) Gecko/20111006 Firefox/10.0a1
Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20100101 Firefox/8.0
Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20100101 Firefox/8.0
Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101 Firefox/8.0
Verified as fixed on the above builds: Firefox doesn't crash after authorizing or submiting tweet.
Still, no data is displayed on nightlies in either of the Echofon's tabs, but I will log another bug for that.