firefox 2.0.0.17 distributed with gutsy security crashes on most sites
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Fix Released
|
Critical
|
|||
firefox-3.0 (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: firefox
Firefox 2.0.0.17 just distributed as a security upgrade to ubuntu gutsy i386 is not usable as it crashes on most sites. E.g. try www.fineco.it
In Mozilla Bugzilla #456705, Steve-england (steve-england) wrote : | #1 |
In Mozilla Bugzilla #456705, 1001110-gmx (1001110-gmx) wrote : | #2 |
Firefox did not crash when I create a new profile. It also does NOT crash if I open https-sites in the new profile.
I did not sent Talkback Crash data - I've enabled it now. Starting Firefox with my default profile makes it crashing again on entering https-sites. It seems to be a problem with one of the extensions.
I have sent a crash report with the following description:
Crash related to:
https:/
I hope that helps
In Mozilla Bugzilla #456705, 1001110-gmx (1001110-gmx) wrote : | #3 |
The Feedback Agent just told me that it was unable to send the report since it is unable to connect to the server. I think there is some firewall on my side that is blocking it.
In Mozilla Bugzilla #456705, Tobbi-bugs (tobbi-bugs) wrote : | #4 |
First of all: I'm not a developer.
As you know that it's a plugin that causes the crash it would now be helpful to know, which plugin of those three crashes. Thus you might have to disable one add-on a time and restart firefox.
First go to Tools > Add-ons. Right click an entry under 'Add-Ons' and click 'disable' in the context menu entry. Restart Firefox.
Then try again to access a https web site.
When you know the add-on that crashes, go to the appropriate web site of this add-on and report the issue there.
Adblock Plus: http://
FoxyProxy: http://
In Mozilla Bugzilla #456705, Steve-england (steve-england) wrote : | #5 |
For future reference, plugins are specifically things like flash, java, etc, whilst extensions are specifically the firefox addons.
In Mozilla Bugzilla #456705, Tobbi-bugs (tobbi-bugs) wrote : | #6 |
(In reply to comment #5)
> For future reference, plugins are specifically things like flash, java, etc,
> whilst extensions are specifically the firefox addons.
You're right and of course I know the difference. Just muddled these two up this time.
In Mozilla Bugzilla #456705, 1001110-gmx (1001110-gmx) wrote : | #7 |
It is a problem with Adblock Plus: Element Hiding Helper 1.0.5 and FoxyProxy 2.8.5. If one of these two extensions is enabled in any combination, Firefox will crash (on https).
Adblock Plus 0.7.5.5 alone will work fine. FoxyProxy (even if enabled alone) will crash Firefox. Adblock Plus: Element Hiding Helper will run only with Adblock Plus. Running the two Adblock Plus extensions together will crash Firefox.
I will go to the extension forums with this problem.
In Mozilla Bugzilla #456705, Chrisretusn (chrisretusn) wrote : | #8 |
Additional info: This is a 100% reproducible problem. Using XP Pro SP3, Fx 2.0.0.17 of course and FoxyProxy 2.8.5. I have 42 installed extensions. Of those one is Adblock Plus 0.7.5.5 which as a previous poster stated causes no problems.
When running Fx in Safe Mode, no problems. Running with all add-ons disabled, no problems. Running with all add-ons enabled except FoxyProxy, no problems. Problems occur only if FoxyProxy is enabled. This is as standalone only add-on installed or with other extensions installed (enabled or disabled).
I have also reported this problem to the author at:
http://
In Mozilla Bugzilla #456705, Steve-england (steve-england) wrote : | #9 |
Is this a regression? Did things work in 2.0.0.16
Sergio Callegari (callegar) wrote : | #10 |
Binary package hint: firefox
Firefox 2.0.0.17 just distributed as a security upgrade to ubuntu gutsy i386 is not usable as it crashes on most sites. E.g. try www.fineco.it
In Mozilla Bugzilla #456705, Timeless-bemail (timeless-bemail) wrote : | #11 |
In Mozilla Bugzilla #456705, Matti-mversen (matti-mversen) wrote : | #12 |
An addon should not be able to crash the browser unless the addon is using binary contents (not only written in JS/xul)
In Mozilla Bugzilla #456705, Chrisretusn (chrisretusn) wrote : | #13 |
(In reply to comment #9)
> Is this a regression? Did things work in 2.0.0.16
In my case things worked in 2.0.0.16, failed after upgrading to 2.0.0.17
In Mozilla Bugzilla #456705, 1001110-gmx (1001110-gmx) wrote : | #14 |
Same here, things where fine in Firefox 2.0.0.16.
In Mozilla Bugzilla #456705, Dveditz (dveditz) wrote : | #15 |
(In reply to comment #11)
> An addon should not be able to crash the browser unless the addon is using
> binary contents (not only written in JS/xul)
True, and yet just as a web page "should not" be able to crash the browser it does sometimes happen.
In Mozilla Bugzilla #456705, Abillings (abillings) wrote : | #16 |
I confirmed the bug. It Foxyproxy 2.8.5 crashes Firefox 2.0.0.17 on first run after installation. On subsequent runs, I'm not seeing it crash.
In Mozilla Bugzilla #456705, Jbecerra-mozilla (jbecerra-mozilla) wrote : | #17 |
Firefox 2.0.0.16 does not crash on shutdown with FoxyProxy 2.8.5, but 2.0.0.17 does. Talkback Id for this crash: TB49885565Z
In Mozilla Bugzilla #456705, Dveditz (dveditz) wrote : | #18 |
I see lots of crashes like TB49885565 at [0x00000000 8560629a] with no stack (i.e. useless), at least one of which mentions FoxyProxy and a couple mention it's constant since upgrading. Also lots of crashes at PL_DHashTableOp
In Mozilla Bugzilla #456705, Matti-mversen (matti-mversen) wrote : | #19 |
*** Bug 457031 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #456705, Matti-mversen (matti-mversen) wrote : | #20 |
*** Bug 456982 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #456705, Matti-mversen (matti-mversen) wrote : | #21 |
Created attachment 340417
Stacktrace for this crash generated with Windbg, from bug 456982
In Mozilla Bugzilla #456705, Cbook (cbook) wrote : | #22 |
Created attachment 340425
stack Mac 10.5.5.
stack using foxyproxy and 2.0.0.17 Debug Build on Mac (Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.18pre Gecko/2008092519 Firefox/
In Mozilla Bugzilla #456705, ericjung (eric-jung) wrote : | #23 |
As author of FoxyProxy, I can tell you that I have no idea how to fix this. Could really use some help. FoxyProxy has no binary components.
In Mozilla Bugzilla #456705, ericjung (eric-jung) wrote : | #24 |
As mentioned in bug 456705, this is affecting roughly 35,000 users. I've confirmed that FoxyProxy with Firefox 2.0.0.17 crashes whenever visiting a SSL site.
In Mozilla Bugzilla #456705, ericjung (eric-jung) wrote : | #25 |
Crash does not occur with versions 2.x versions of Firefox before 2.0.0.17, and it doesn't occur with Firefox 3.x.
In Mozilla Bugzilla #456705, Jesper Staun Hansen (jesper-staun-hansen-deactivatedaccount) wrote : | #26 |
Created attachment 340463
backtrace on ubuntu
Attached is the backtrace for ubuntu
In Mozilla Bugzilla #456705, Dveditz (dveditz) wrote : | #27 |
This seems a consistent enough crash that we can narrow down the regression window -- that'd be a good start.
In Mozilla Bugzilla #456705, Cbook (cbook) wrote : | #28 |
i will work on a regression range for this bug.
In Mozilla Bugzilla #456705, Timeless-bemail (timeless-bemail) wrote : | #29 |
well, here are some problems (based on attachment 340417):
http://
nsSSLIOLayerHel
http://
nsNSSComponent:
this code is broken:
http://
it should null out mutex because it's not a class variable, it's a static.
attachment 340425 deals w/ a different mutex which seems less likely to be dead in the same way, afaict it should be alive here:
1022 nsAutoLock threadLock(
and unhappy here:
1046 nsAutoLock threadLock(
note that conceivably if the lifespan of the thread is wrong, bad things could happen, however i'm not able to find an obvious path for this (and finding a pretty source browser for foxyproxy was hard, so i gave up [yes, i downloaded the addon itself, but i have to pack for vacation or something...]).
attachment 340463 is different. table is null. it could stem from failing to check the Init method:
http://
but again this is unlikely (although it is a bug).
In Mozilla Bugzilla #456705, Timeless-bemail (timeless-bemail) wrote : | #30 |
eric, this comment's for you (comment 28 was for kaie):
proxy.js has:
fileProtoco
which is wrong. protocolhandlers are singletons. the proper way to get one can be found here:
http://
mook points out that nsIProtocolHandlers aren't usefully threadsafe, you must get a proxy for them, and in fact, you really want them to give you proxied objects, otherwise what you get is fairly useless.
you should look at some patches i've done involving nsIURIs and crashing (i think i may have even written some of them at your place)
In Mozilla Bugzilla #456705, Dveditz (dveditz) wrote : | #31 |
Kai: comment 28 was for you
Sergio Callegari (callegar) wrote : | #32 |
Actually a (serious) regression of 2.0.0.17 also affecting Windows versions.
Many bugs reports indicate this as triggered by pages including https stuff and by the usage of the foxyproxy extension.
But an extension /not containing/ binary code should not crash the browser unless there is some issue issue in the browser itself.
See https:/
In Mozilla Bugzilla #456705, ericjung (eric-jung) wrote : | #33 |
@timeless: pretty source browser for foxyproxy is here: http://
I've replaced all references of CC["@mozilla.
Instead of explicitly creating proxy objects for the service (can that be done in JS?), I've tried to ensure that use of the nsIFileProtocol
IOW, this kind of code:
var fph = CC["@mozilla.
function doStuff() {
// use fph here. fcn may be called whenever and by whomever
}
has been converted to this kind of code:
function doStuff() {
var fph = CC["@mozilla.
// use fph here. fcn may be called whenever and by whomever
}
Is that sufficient to guarantee single-threaded use of the service within JS?
In Mozilla Bugzilla #456705, Cbook (cbook) wrote : | #34 |
Found the regression window:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17pre)
Gecko/2008082603 BonEcho/2.0.0.17pre - works on SSL Sites with Proxyproxy
installed -> no crash
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17pre)
Gecko/2008082703 BonEcho/2.0.0.17pre - fails on SSL Sites with Proxyproxy
installed -> crash
Bonsai Query for this Timeframe -> http://
In Mozilla Bugzilla #456705, Dveditz (dveditz) wrote : | #35 |
(In reply to comment #32)
> Bonsai Query for this Timeframe -> http://
This crash goes away if I back out the fix for bug 445890 ("XMLHttpReques
FoxyProxy uses XMLHttpRequest to load a PAC file, load strings from a chrome: URI, and load an .xml settings file out of the prefs. I don't know what XMLHttpRequest and multiple instances of the file protocol handler have to do with crashing on SSL connections.
In Mozilla Bugzilla #456705, Dveditz (dveditz) wrote : | #36 |
> and load an .xml settings file out of the prefs
I meant "profile [directory]".
In Mozilla Bugzilla #456705, ericjung (eric-jung) wrote : | #37 |
(In reply to comment #33)
> This crash goes away if I back out the fix for bug 445890
> ("XMLHttpReques
>
> FoxyProxy uses XMLHttpRequest to load a PAC file, load strings from a chrome:
> URI, and load an .xml settings file out of the prefs. I don't know what
> XMLHttpRequest and multiple instances of the file protocol handler have to do
> with crashing on SSL connections.
I don't know if this helps, but FoxyProxy does define a custom protocol handler (see components/
From the FoxyProxy help:
For PAC files on an ftp server, use the ftp:// scheme. For example, ftp://leahscape
In Mozilla Bugzilla #456705, Dveditz (dveditz) wrote : | #38 |
With FoxyProxy enabled I get lots of these even before I try to visit an SSL sites:
###!!! ASSERTION: nsNSSComponent is a singleton, but instantiated multiple times!: '(0 == mInstanceCount)', file /Users/
###!!! ASSERTION: nsSSLThread is a singleton, caller attempts to create another instance!: '!ssl_thread_
Break: at file /Users/
###!!! ASSERTION: nsCertVerificat
Break: at file /Users/
...mostly for nsNSSComponent. With the FoxyProxy addon removed i don't see those.
In Mozilla Bugzilla #456705, Dveditz (dveditz) wrote : | #39 |
Now I can tie the NSS assertion, FoxyProxy, and the XMLHttpRequest change together. In 2.0.0.17 w/FoxyProxy the first call to the nsNSSComponent constructor is due to FoxyProxy doing a XMLHttpRequest to load "chrome:
The change in bug 445890 tried to set an owner on the channel, but mPrincipal was null. If there had been an owner that would have avoided the jar signature check. In other uses (loading our own resources) the jar channels usually have an explicit system principal owner -- maybe XMLHttpRequest should be using that when called from chrome?
Not always though: when we load chrome:
If foxyproxy were "flat" instead of jarred this wouldn't come up, but that's ducking the issue.
Using XMLHttpRequest on a chrome: resource seems like an abuse of the feature, but I suppose it's an attractive nuisance to have a feature that does so much for you. Stringbundle is the feature made for loading localized strings, but that's a little more code. Is it a common pattern for addons to avoid stringbundles by using XML entities and XHR instead?
In Mozilla Bugzilla #456705, ericjung (eric-jung) wrote : | #40 |
(In reply to comment #37)
> Stringbundle is the feature made for loading localized strings, but
> that's a little more code. Is it a common pattern for addons to avoid
> stringbundles by using XML entities and XHR instead?
The use of localized XML entities here is a way to avoid redundant translation strings. To elaborate:
I do indeed use a stringbundle (search for chrome:
I would speculate this pattern isn't done frequently, but I do know at least one other major extension which does it--FoxClocks. Andy McDonald, FoxClocks author, was the one who coined this idea AFAIK.
I am open to alternative uses of stringbundles/DTD files/etc to avoid double translation issues... please let me know if Andy and I have missed the obvious!
> If foxyproxy were "flat" instead of jarred this wouldn't come up, but that's
> ducking the issue.
I realize you're trying to fix the underlying cause. At the moment, I'm trying to patch FoxyProxy so Firefox 2.x users can use it. With that in mind, do you know if this would come up if I avoid XHR for reading strings.xml and instead use a file input stream?
Changed in firefox: | |
status: | Unknown → Confirmed |
Changed in firefox: | |
status: | Confirmed → In Progress |
40 comments hidden Loading more comments | view all 120 comments |
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #81 |
Created attachment 361403
v2 for 1.8
There is no need to worry about races, we are protected by monitor of nsComponentMana
What you suggest in comment 76 will work (first tests show it still works). Only in case we first create nss component service independently and then we create a component that ensure the nss service we call do_GetService for it a second time. It's probably a very little overhead.
Tested again on 1.8.1 branch with FoxyProxy 2.8.5 and reversed patch for bug 462806.
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #82 |
Created attachment 361404
v2 for 1.9.1 and trunk
In Mozilla Bugzilla #456705, Kai Engert (kaie) wrote : | #83 |
Honza, I have a problem with your patch, but I don't know yet where the problem is. I'm currently working on a patch for bug 390036, it introduces additional SSL worker threads.
Whenever I merge your patch here with the patch from there, I get assertions that multiple instances of nsNSSComponent get created (with session restore of a https page).
My patch alone: works fine
Your patch alone: works fine
The new combination, or your changed order of init calls, or the changed logic of the XPCOM-constructor macro, or a side effect in my patch. So far I was unable to find the cause.
In Mozilla Bugzilla #456705, Kai Engert (kaie) wrote : | #84 |
Created attachment 361986
merge test (a)
This is your trunk patch with my new feature patch from bug 390036 merged.
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #85 |
Created attachment 361994
fix for the merge test (a)
>diff --git a/security/
>--- a/security/
>+++ b/security/
>@@ -1747,9 +1762,25 @@ nsNSSComponent:
> rv = InitializeNSS(
> if (NS_FAILED(rv)) {
> PR_LOG(gPIPNSSLog, PR_LOG_ERROR, ("Unable to Initialize NSS.\n"));
>+
>+ DeregisterObser
>+ mPIPNSSBundle = nsnull;
> return rv;
> }
>
>+ nsSSLIOLayerHel
>+ nsSSLThreadCont
>+ nsSSLThreadCont
>+ mCertVerificati
>+ if (mCertVerificat
>+ mCertVerificati
>+
>+ if (!mSSLThread || !mCertVerificat
>+ {
>+ PR_LOG(gPIPNSSLog, PR_LOG_DEBUG, ("NSS init, could not create threads\n"));
>+ return NS_ERROR_
>+ }
You left here !mSSLThread in the condition. Should be nsSSLThreadCont
Also, it's obviously my fault that I do not deregister observers on this failure, that is why you got two instances, I have to add it to my patch for bug 456705.
In Mozilla Bugzilla #456705, Kai Engert (kaie) wrote : | #86 |
Thanks Honza! That helps me.
Will you attach a new patch to this bug, where you fix the observers?
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #87 |
(In reply to comment #83)
> Will you attach a new patch to this bug, where you fix the observers?
Yes, probably today.
Sergio Callegari (callegar) wrote : | #88 |
I believe that this bug report can be closed. The issue appeared to be caused by a bad interaction between foxyproxy and firefox.
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #89 |
Created attachment 362318
v2.1 for 1.9.1 and trunk
Fixing pre-return code in nsNSSComponent:
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #90 |
Created attachment 362319
v2.1 for 1.8
In Mozilla Bugzilla #456705, Kai Engert (kaie) wrote : | #91 |
Comment on attachment 362318
v2.1 for 1.9.1 and trunk
r=kaie
In Mozilla Bugzilla #456705, Kai Engert (kaie) wrote : | #92 |
Comment on attachment 362319
v2.1 for 1.8
r=kaie
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #93 |
Comment on attachment 362318
v2.1 for 1.9.1 and trunk
I'll land this soon on trunk.
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #94 |
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #95 |
Cause getService re-entrance, I had to catch this, reverting to the first version of the patch that prevents this.
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #96 |
Ok, for now I backed out, it is not that simple to return to the first version of the patch, I have to retest all the stuff again, it's for hours...
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #97 |
Created attachment 363903
v3, trunk, 1.9.1
I added one more flag, that's set TRUE during nss component is in process of initiation. This prevents reenter of do_GetService for it (that leads to assertion false) and cleans the whole code up.
I change the flags only and only when called from nss component constructor now that prevents any race conditions - we are protected by XPCOM component manager monitor.
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #98 |
Created attachment 363906
v3, for 1.8.1
Tested again with patch -R bz's fix and FoxyProxy 2.8.5.
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #99 |
Created attachment 363916
v3.1, trunk, 1.9.1
Found a little mistake in the constructor, I was calling EnsureNSSInitia
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #100 |
Created attachment 363917
v3.1, 1.8.1
...
In Mozilla Bugzilla #456705, Kai Engert (kaie) wrote : | #101 |
Comment on attachment 363916
v3.1, trunk, 1.9.1
Honza, thanks a lot.
r=kaie
In Mozilla Bugzilla #456705, Kai Engert (kaie) wrote : | #102 |
Comment on attachment 363917
v3.1, 1.8.1
r=kaie
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #103 |
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #104 |
Backed out, we get assertion failure on leak test boxes, see bottom of
http://
Changed in firefox: | |
status: | In Progress → Confirmed |
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #105 |
Created attachment 364570
v3.2 [Checkin mozilla-central comment 102][Checkin mozilla-1.9.1 comment 106]
Ok, no assertions anymore, re-entrance protection was to protective.
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #106 |
Changed in firefox: | |
status: | Confirmed → Fix Released |
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #107 |
Created attachment 364968
v3.2 for 1.8.1 [Checkin comment 109]
3.2 successfully landed on mozilla-central, we can try to land on 1.8.1. Locally deeply tested as STR for this bug is for FF 2.0.
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #108 |
Comment on attachment 364570
v3.2 [Checkin mozilla-central comment 102][Checkin mozilla-1.9.1 comment 106]
Successfully landed on mozilla-central.
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #109 |
Created attachment 365009
v3.2 for 1.9.0 [Checkin comment 111]
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #110 |
Comment on attachment 364570
v3.2 [Checkin mozilla-central comment 102][Checkin mozilla-1.9.1 comment 106]
(As it's blocking 1.9.1 doesn't need approval)
http://
John Vivirito (gnomefreak) wrote : | #111 |
2.0 is no loager supported adn for future crash reports please use apport to file it.
Changed in firefox-3.0 (Ubuntu): | |
status: | New → Invalid |
In Mozilla Bugzilla #456705, Dveditz (dveditz) wrote : | #112 |
Comment on attachment 364968
v3.2 for 1.8.1 [Checkin comment 109]
Approved for 1.8.1.22, a=dveditz for release-drivers
In Mozilla Bugzilla #456705, Dveditz (dveditz) wrote : | #113 |
If this fixes topcrash bug 427715 then it'd be worth taking for sure.
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #114 |
Comment on attachment 364968
v3.2 for 1.8.1 [Checkin comment 109]
Checking in nsNSSComponent.cpp;
/cvsroot/
new revision: 1.126.2.10; previous revision: 1.126.2.9
done
Checking in nsNSSComponent.h;
/cvsroot/
new revision: 1.38.4.4; previous revision: 1.38.4.3
done
Checking in nsNSSIOLayer.cpp;
/cvsroot/
new revision: 1.97.2.21; previous revision: 1.97.2.20
done
Checking in nsNSSIOLayer.h;
/cvsroot/
new revision: 1.27.28.6; previous revision: 1.27.28.5
done
Checking in nsNSSModule.cpp;
/cvsroot/
new revision: 1.38.4.2; previous revision: 1.38.4.1
done
In Mozilla Bugzilla #456705, Dveditz (dveditz) wrote : | #115 |
Comment on attachment 365009
v3.2 for 1.9.0 [Checkin comment 111]
Approved for 1.9.0.10, a=dveditz for release-drivers
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #116 |
Comment on attachment 365009
v3.2 for 1.9.0 [Checkin comment 111]
Landed on 1.9.0.
Checking in nsNSSComponent.cpp;
/cvsroot/
new revision: 1.168; previous revision: 1.167
done
Checking in nsNSSComponent.h;
/cvsroot/
new revision: 1.54; previous revision: 1.53
done
Checking in nsNSSIOLayer.cpp;
/cvsroot/
new revision: 1.165; previous revision: 1.164
done
Checking in nsNSSIOLayer.h;
/cvsroot/
new revision: 1.47; previous revision: 1.46
done
Checking in nsNSSModule.cpp;
/cvsroot/
new revision: 1.52; previous revision: 1.51
done
In Mozilla Bugzilla #456705, Dietrich-mozilla (dietrich-mozilla) wrote : | #117 |
This sent fxdbug-linux-tbox all leaky on 1.9.0.
In Mozilla Bugzilla #456705, Samuel-sidler+old (samuel-sidler+old) wrote : | #118 |
(In reply to comment #112)
> This sent fxdbug-linux-tbox all leaky on 1.9.0.
Since it's never more than 92.0B, you're likely seeing bug 454837.
In Mozilla Bugzilla #456705, Honzab-moz (honzab-moz) wrote : | #119 |
I believe that leak is not caused by my land. As I was watching the tree, it failed before already the same way. Just after my check-in it happened more often, but not in 100% cases, there were also greens. I'll check the leaks, my patch may be somehow related.
In Mozilla Bugzilla #456705, Abillings (abillings) wrote : | #120 |
Verified for 1.9.0.11 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11pre) Gecko/2009051305 GranParadiso/
Changed in firefox: | |
importance: | Unknown → Critical |
When you crash do you submit any Talkback Crash data?
Does the crash happen if you make a new profile for a test? support. mozilla. com/en- US/kb/Managing+ profiles
- http://