519729 - Crash [@nsHttpsHandler::GetProtocolFlags(unsigned int*)] with COMPUTERBILD Abzockschutz addon

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Carsten Book [:Tomcat]]

Crash filed from the Top Crash Stats (looks like in some cases like a crash on startup or shortly after) :

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.5.3&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsHttpsHandler%3A%3AGetProtocolFlags%28unsigned%20int*%29

the Comments mentioned no real steps to reproduce - one comment mention norton sercurity2010 - but unclear if this cause the crash here. Maybe a url list would be helpful for reproducing this crash ?

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

These have short uptimes (startup crash) and there aren't useful URLs.

Comment 2

[Carsten Book [:Tomcat]]

(In reply to comment #1)
> These have short uptimes (startup crash) and there aren't useful URLs.

i checked one url from the comment (a kind of home-shopping-tv-station site) but no crash, david, do you have any more idea how to reproduce this crash ?

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This seems very highly correlated with addons:

  nsHttpsHandler::GetProtocolFlags(unsigned int*)|EXCEPTION_ACCESS_VIOLATION (142 crashes)
     99% (141/142) vs.   0% (268/95088) {d49175b3-3fd8-43b8-b28e-da5d47f3c398}
     81% (115/142) vs.   2% (2188/95088) {7BA52691-1876-45ce-9EE6-54BCB3B04BBC}
     79% (112/142) vs.   3% (2792/95088) {8545daff-ad1e-493f-a37e-eed1ac79682b}
(and others, with weaker correlations)

and with libraries:

  nsHttpsHandler::GetProtocolFlags(unsigned int*)|EXCEPTION_ACCESS_VIOLATION (142 crashes)
     97% (138/142) vs.   3% (3056/95088) EFACli.dll
     97% (138/142) vs.   3% (3070/95088) ccIPC.dll
     97% (138/142) vs.   3% (3080/95088) coFFPlgn.dll
     97% (138/142) vs.   3% (3174/95088) ccVrTrst.dll
     95% (135/142) vs.   3% (2821/95088) Scxpx86.dll
     95% (135/142) vs.   3% (3052/95088) IPSFFPl.dll
     81% (115/142) vs.   3% (2858/95088) ccL80U.dll
     68% (97/142) vs.   1% (1031/95088) isDataPr.dll
     68% (97/142) vs.   2% (2058/95088) IVPlugin.dll
     68% (97/142) vs.   2% (2062/95088) coUICtlr.dll
     68% (97/142) vs.   2% (2062/95088) coWPPlg.dll
     68% (97/142) vs.   2% (2125/95088) ccSet.dll

http://dbaron.org/mozilla/topcrash-modules

Comment 4

[Samuel Sidler (old account; do not CC)]

Bing returns a result on http://forum.computerbild.de/dsl-wlan/google-schaden_52972.html

The extension is listed here:

- COMPUTERBILD-Abzockschutz 1.0.20
{d49175b3-3fd8-43b8-b28e-da5d47f3c398}
http://www.computerbild.de
Firefox 3.0 - 3.*
COMPUTERBILD-Abzockschutz

Comment 5

[chris hofmann]

libraies listed in comment 3 are Symantec

ccipc.dll is a Symantec ccIPC Engine\r belonging to Symantec Security Technologies\r from Symantec Corporation\r 

efacli.dll is a SymEFA\r belonging to EFA\r from Symantec Corporation\r

the comments I see from last few days are *all* in german.

http://translate.google.com/translate?prev=hp&hl=en&js=y&u=http%3A%2F%2Fwww.camp-firefox.de%2Fforum%2Fviewtopic.php%3Ff%3D1%26t%3D75379&sl=de&tl=en&history_state0=

I think indicates turning off norton fixed the problem

Comment 6

[chris hofmann]

kev, another one we could probably use some symantec help in looking at.

Comment 7

[Samuel Sidler (old account; do not CC)]

I don't think this is Symantec. I think this is the problem extension listed in comment 4 (with a 99% correlation, per comment 3).

Comment 8

[chris hofmann]

ok,  sam might be on to something.  all comments for the last several days on this signature are in german.

here is the google translation of all those comments

	

comments for nsHttpsHandle

20091004-crashdata.csv

nsHttpsHandler:: GetProtocolFlags (unsigned int *)
Sorry | | A problem has occurred, and Firefox crashed. It tries to restore your tabs and windows when it restarts. | | This inscription is permanent. | MfG M. Josupeit

Firefox 3.5.3 Windows NT 5.1.2600 Service Pack 3

20091005-crashdata.csv

nsHttpsHandler:: GetProtocolFlags (unsigned int *)
It only helps to uninstall. After the subsequent reinstallation of Firefox can be started only once. Thereafter, the FireFox stürtzt when starting.

Firefox 3.5.3 Windows NT 5.1.2600 Service Pack 3


nsHttpsHandler:: GetProtocolFlags (unsigned int *)
For some time Firefox does not work reliably. Hofente change this soon, sont I change the browser

Firefox 3.5.3 Windows NT 6.0.6001 Service Pack 1

20091006-crashdata.csv

nsHttpsHandler:: GetProtocolFlags (unsigned int *)
Last time it happened very often that crashes firefox only with me??

Firefox 3.5.3 Windows NT 5.1.2600 Service Pack 3

20091007-crashdata.csv

nsHttpsHandler:: GetProtocolFlags (unsigned int *)
Since yesterday, I installed Norton 360 online, it comes with Firefox, this Startabstürzen. When I loaded a web page, sometimes I can select anything. Others in the background running program can not be activated. It was only when I use the Task Manager views, I can for a limited select something on the website. |. .

Firefox 3.5.3 Windows NT 5.1.2600 Service Pack 3


nsHttpsHandler:: GetProtocolFlags (unsigned int *)
When Firefox from 2 start times will be no longer possible einwahl to the Internet (Page)

Firefox 3.5 for Windows NT 6.0.6002 Service Pack 2


nsHttpsHandler:: GetProtocolFlags (unsigned int *)
I have the same snout full: (

Firefox 3.0.14 Windows NT 6.1.7100


nsHttpsHandler:: GetProtocolFlags (unsigned int *)
mozilla can not open any programs while but

Firefox 3.0.14 Windows NT 6.0.6002 Service Pack 2


nsHttpsHandler:: GetProtocolFlags (unsigned int *)
When running back fierfox?

Firefox 3.5.3 Windows NT 6.0.6002 Service Pack 2

20091008-crashdata.csv

nsHttpsHandler:: GetProtocolFlags (unsigned int *)
I have already sent dozens of times. Perhaps you could send me ja mal an info !!!!!!!!!!

Firefox 3.5.2 Windows NT 6.0.6002 Service Pack 2

20091009-crashdata.csv

nsHttpsHandler:: GetProtocolFlags (unsigned int *)
Firefox keeps crashing when the computer out of standby is put back into operation.

Firefox 3.5.3 Windows NT 5.1.2600 Service Pack 3


nsHttpsHandler:: GetProtocolFlags (unsigned int *)
Mozilla opens ok.Aber only when 1.Mal. After a close while he opens it, but I can not open a page-it is to see a ban on signs. In emails I can not open

Firefox 3.5.3 Windows NT 5.1.2600 Service Pack 3


nsHttpsHandler:: GetProtocolFlags (unsigned int *)
More recently it crashes always. Reinstall does not help. Internet Explorer works fine. | Werner Kalkert

Firefox 3.5.3 Windows NT 6.0.6002 Service Pack 2


nsHttpsHandler:: GetProtocolFlags (unsigned int *)
This is einscheis can use mozilla nima

Firefox 3.5.3 Windows NT 6.0.6001 Service Pack 1



20091010-crashdata.csv

nsHttpsHandler:: GetProtocolFlags (unsigned int *)
Cause is a new antivirus program

Firefox 3.5.3 Windows NT 5.1.2600 Service Pack 

20091011-crashdata.csv

nsHttpsHandler:: GetProtocolFlags (unsigned int *)
It always crashes when it turns on, from

Firefox 3.5.3 Windows NT 6.1.7600

20091012-crashdata.csv

nsHttpsHandler:: GetProtocolFlags (unsigned int *)
It often happens here the firefox crashes

Firefox 3.5.3 Windows NT 6.1.7100


nsHttpsHandler:: GetProtocolFlags (unsigned int *)
people get help here too times .... it was the 50th absturz,,, to vomit

Firefox 3.5.3 Windows NT 5.1.2600 Service Pack 3


nsHttpsHandler:: GetProtocolFlags (unsigned int *)
www.qvc.de
about: blank
Firefox 3.5.3 Windows NT 5.1.2600 Service Pack 3

Comment 9

[Johnathan Nightingale [:johnath]]

ComputerBild is a German print and online tech mag that often packages CDs & Software with their magazine. I met with them in the summer, I'll find a contact here.

Comment 10

[Johnathan Nightingale [:johnath]]

Okay, I have a contact at ComputerBild - is someone on point for investigating this crash?

Comment 11

[Carsten Book [:Tomcat]]

(In reply to comment #10)
> Okay, I have a contact at ComputerBild - is someone on point for investigating
> this crash?

i will install this extension to check this crash.

Comment 12

[Johnathan Nightingale [:johnath]]

Great. I have emailed the contact at ComputerBild and cc'd Sam and Carsten as well. My hope is that he will comment here once he has had a chance to investigate it.

Comment 13

[Johnathan Nightingale [:johnath]]

From Sven, one of the authors of the plugin:

Hello Jonathan,

first of all let me say that we at J3S really love the Firefox
and are happy to help you as much as we can to fix the problem.
The COMPUTERBILD-Abzockschutz extension is fully JS and XUL
based, thus we believe that such an extension "should not" (be
able to..) cause an exception, but we use some components which
might be the cause for this bug.

Here are some insights on the extension:

a.) I attached the most recent XPI

b.) The extension downloads a list of "bad" sites and when the
user navigates to such site it gets an error/warning stating
the specific site is not "good" for the user. We do this by
implementing a protocol handler which checks the url and
intercepts the data with our own HTML code for blocked sites.
The underlying code snippets are based on your example code,
still we believe this might be linked to the mentioned problem

c.) Specific information about the startup: it seems that many
people experiencing the exception do so when firefox starts up.
Upon startup we update register the protocol handler and update
the blacklist file. We believe this might happen (for what
reason whatsover) too early, so that one (internally) required
component might not be availble at that specific time.

You might want to take a look at
c1.) overlay.js:23 which is calling
c2.) engine.js.62: init which is registering the component and
updating the domain list afterwards.

If we could reproduce it we would try commenting out either one
of the to points mentioned in c2 to see if it causes the
problem. Our guess is that if the update of the domains is
called later (setTimout?) it might already fix the problem.

Comment 14

[Johnathan Nightingale [:johnath]]

And my reply:

Thanks so much for your willingness to help, your detailed preliminary  
analysis, and your kind words about Firefox. I'm certain that with  
this kind of cooperation, we can get this matter solved.  I've copied  
another of my colleagues, Justin Dolske, on this email chain, since he  
has done a great deal of crash analysis work in the last little while.

Knowing that your addon is 100% JS/XUL, without binary components, is  
a big help since, as you say, that "should" make it more resilient to  
this kind of thing. And your hunch about when the update runs is also  
a promising thing to investigate. Incidentally, we typically update  
our own list of "bad" sites approximately 15 minutes after startup.  
Not only does this ensure that all XPCOM components are alive and  
well, it also ensures that users don't experience slowdowns at startup  
because of these checks. They can launch the browser quickly, go to  
the site they wanted the browser for, and then not notice when we  
start updating the list later. For these reasons, independent of the  
crash here, it's an approach you may wish to consider.

I have added your bugzilla account to the bug in question so that you  
can follow the updates there. With your permission, I would also like  
to copy the contents of this email there, so that others can read up  
on your summary. I believe Tomcat (Carsten) will be trying to recreate  
the crash on our end, while we look into some of the points you raise  
regarding the parts of your code that may be uncovering bugs in our  
own. In the meantime, if you do update your extension to use a timeout  
for the initial fetch, we can monitor the incoming crash reports to  
see if they are reduced, or if they continue to occur on the new  
version.

Comment 15

[Justin Dolske [:Dolske]]

So, the crashing line is:

    return gHttpHandler->GetProtocolFlags(aProtocolFlags);

Crash reports indicate it's a null dereference, so it's most likely gHttpHandler is null.

Looks to me like the code is assuming we'll always touch a http:// before a https:// URL (the nsHttpHandler constructor will cache gHttpHandler). So at first glance this sounds like a bug in our code. The stuff in comment 13 sounds like the extension is doing a network request early in startup, so that could certainly cause this... I'm not sure what else touches the http:// path during startup, if there's just a race here that would explain why sometimes it crashes and sometimes it doesn't.

On a side note, the crashreporter's uptime value is probably thus an interesting real-world sample of startup times to this point in the code! :)

Comment 16

[chris hofmann]

Attachment: start times

re: real world start times 

I've been looking at and grouping the "time since last crash" for a few months now and there is some noise and bogus reports in the data.  for this particular crash signature on a days worth of data it looks something like this:

 report for the stack signature nsHttpsHandler::GetProtocolFlags 

 136 total crashes for nsHttpsHandler::GetProtocolFlags on 20091019-crashdata.csv
 65 start up crashes inside 3 minutes
 147.575 (days) total uptime for 132 of these crashes where user crashed within the last year 
 1609.91 (minutes) avg time since last crash 
 4  number of bogus time-since-last-crash reported for this signature 

plot of these start times shows a mean start time of around 40 seconds for the reports inside 260 seconds of uptime.

Comment 17

[chris hofmann]

Attachment: a bit more detailed chart

Comment 18

[chris hofmann]

took the real world startup tracking ideas to bug 523777

Comment 19

[Daniel Veditz [:dveditz]]

> The COMPUTERBILD-Abzockschutz extension is fully JS and XUL
> based, thus we believe that such an extension "should not" (be
> able to..) cause an exception, but we use some components which
> might be the cause for this bug.

XUL alone, and JavaScript that manipulates the XUL DOM "should" be safe, and crashes doing that kind of thing are almost certainly Firefox bugs. But when you mess with components you have to know and play by the (probably undocumented) rules for those components. It's a bit like crashing when calling strlen(NULL) in a C program. The C runtime could be written to handle that case, but it slows everything down if you have to double-check all the time on "internal" interfaces where the callers are supposed to do the right thing.

Start up and shutdown are particularly cranky -- addons should steer well clear if they can.

Comment 20

[J3S GmbH]

1.) You stated our problem:  "probably undocumented" - implementation was not too much fun there and involed "backward analysing"

We totally agree on trying to avoid unecessary double checks resulting in a performance hit for every user and to change/fix/workaround in our code '), but currently we do not know what we are doing wrong. Maybe you could point out the problem?

') and already did so and are currently checking this with a customer reporting a crash)

Comment 21

[J3S GmbH]

The delayed update of domain list did not help for the mentioned reader of Computerbild.

If the reader is experiencing the issue mentioned here, then we need some other approaches to fix this..

Comment 22

[Damon Sicore (:damons)]

jonath can you update bug 523902 with the contact info for ComputerBild?

Comment 23

[Samuel Sidler (old account; do not CC)]

Added as a private comment for Johnathan since he's out today and tomorrow.

Comment 24

[Justin Dolske [:Dolske]]

Could we get a copy of version 1.0.20 (which I believe is a version known to cause this issue?). The website version is 1.0.24, I'm not sure if this has been updated to try and address the problem?

From a brief look at 1.0.24, it's actually the first thing to trigger the creation of a nsHttpHandler (where gHttpHandler is set)... The add-on's component observes xpcom-startup, and immediately does a getService(Ci.nsIHttpProtocolHandler) to pull some fields out.

The code paths that lead to where the crash would occur (via XMLHttpRequest) seem to be triggered by either a WebProgressListener or the chome window's load event. So that would seem to imply that for 1.0.24 to be crashing, the component would have to be seeing xpcom-startup *after* we've created a chrome window, which I wouldn't expect to be possible.

Comment 25

[Justin Dolske [:Dolske]]

Attachment: Patch v.1

This should prevent the crash. But until I can reproduce the crash, I can't be sure that it just crashes elsewher (or, to be paranoid, that the retval here doesn't cause a different flavor of crash :).

There are quite a few places in the code that gHttpHandler is used without a null check. Only one place, in nsHttpAuthManager.cpp, tries to handle that case. I'd suspect that these uses may very well be safe in practice, but I would have suspected that for the spot that's crashing too. Someone more familiar with the network code should probably weigh in here.

Just to be double-clear, we should still diagnose exactly how the add-on is causing this and push a fix that way too (since that will reach users first). This is a belt-and-suspenders fix, to help make sure that other extensions don't accidentally do the same thing and cause topcrashes.

Comment 26

[J3S GmbH]

Version 1.0.20 can be downloaded here:

http://www.j3s.de/COMPUTERBILD-Abzockschutz-1.0.20.xpi

Comment 27

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #15)
> Looks to me like the code is assuming we'll always touch a http:// before a
> https:// URL (the nsHttpHandler constructor will cache gHttpHandler).

That is incorrect. nsHttpsHandler::Init will create the HTTP handler. I do not want to r+ the patch without knowing why the crash happens exactly.

Comment 28

[Justin Dolske [:Dolske]]

Comment on attachment 407927 [details] [diff] [review]
Patch v.1

Doh, you're right, forgot about xpcom constructors.

So, I'd guess that the getService in Init() failed for some reason. Or XPCOM goofed and Init() wasn't even called (but that seems very unlikey). Or, hmm, possibly a GC issue? If nsHttpsHandler's Init() is the first thing to spin up nsHttpHandler, when Init() returns the nsCOMPtr goes out of scope, would trigger the nsHttpHandler's destructor, which in turn sets gHttpHandler to null.

Comment 29

[Justin Dolske [:Dolske]]

Hmm, I'm able to make the extension be the first one to create a nsHttpHandler by:

* setting browser.startup.homepage_override.mstone to ignore
* Clear history, delete the toolbar bookmarks
* Remove default search engine plugins from appdir
* Set homepage to about:blank

But things work fine (testing with 1.0.20).

Another possibility might be if something is overriding the default HTTP handler contract ID... The getService() calls would be running other code, so gHttpHandler would always be null. Not sure if you can really do that (especially given all the other places this would fail!).

The crash is correlated with a couple other addons, some highly, so it might be that if the above is true, you need another addon installed that does this to crash...

Comment 30

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #28)
> Or, hmm,
> possibly a GC issue? If nsHttpsHandler's Init() is the first thing to spin up
> nsHttpHandler, when Init() returns the nsCOMPtr goes out of scope, would
> trigger the nsHttpHandler's destructor, which in turn sets gHttpHandler to
> null.

The service manager has a reference too, which will keep the http handler alive. I suppose it's possible that getting the http service failed... somewhat unlikely.

My thought was that it's perhaps a shutdown crash - http handler geting destroyed before the https handler, and something wants to make an https request in between, but that seems unlikely, and the stacks don't seem to be shutdown stacks afaict.

hm, overridden http handler is a possibility. do we know the list of addons that were installed?

Comment 31

[chris hofmann]

here is short sample of the correlations of addons installed in the module lists of crash reports.   more at 

http://people.mozilla.com/crash_analysis/20091022/20091022_Firefox_3.5.3-interesting-addons-with-versions.txt

nsHttpsHandler::GetProtocolFlags(unsigned int*)|EXCEPTION_ACCESS_VIOLATION (107 crashes)
    100% (107/107) vs.   0% (257/99491) {d49175b3-3fd8-43b8-b28e-da5d47f3c398}
     69% (74/107) vs.   2% (2393/99491) {7BA52691-1876-45ce-9EE6-54BCB3B04BBC}  --- Norton IPS  http://www.lifehacker.com.au/2009/06/remove-norton-ips-and-toolbar-extensions-from-firefox/

     66% (71/107) vs.   3% (2997/99491) {8545daff-ad1e-493f-a37e-eed1ac79682b} (1.0)   -- Norton ISP http://community.norton.com/norton/board/message?board.id=nis_feedback&message.id=68581

     80% (86/107) vs.  43% (42330/99491) {20a82645-c095-46ed-80e3-08825760534b} (Microsoft .NET Framework Assistant, http://www.windowsclient.net/)

     39% (42/107) vs.  10% (9553/99491) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus, https://addons.mozilla.org/addon/1865)

     29% (31/107) vs.   0% (311/99491) {4C0766D3-67A7-45a3-85A2-752F77312F32} (4.0) Norton ISP -- http://forums.maddoktor2.com/index.php?showtopic=26918

     28% (30/107) vs.   0% (471/99491) {BBDA0591-3099-440a-AA10-41764D9DB4DB} (2.0)  Norton ISP -- http://forums.maddoktor2.com/index.php?showtopic=26918

     24% (26/107) vs.   3% (3124/99491) {DDC359D1-844A-42a7-9AA1-88A850A938A8} (DownThemAll!, https://addons.mozilla.org/addon/201)

     22% (24/107) vs.   2% (1669/99491) {0545b830-f0aa-4d7e-8820-50a4629a56fe} (ColorfulTabs, https://addons.mozilla.org/addon/1368)

     21% (23/107) vs.   1% (1244/99491) {CE6E6E3B-84DD-4cac-9F63-8D2AE4F30A4B} (CoolPreviews, https://addons.mozilla.org/addon/2207)

[e-mail] (1.0.0.25)
     21% (22/107) vs.   2% (1670/99491) {0538E3E3-7E9B-4d49-8831-A227C80A7AD3} (Forecastfox, https://addons.mozilla.org/addon/398)


....

Comment 32

[chris hofmann]

a variety of different versions of Norton ISP show up in the list above and there is the note back in comment 5 indicating a user solved the problem by turning off Norton ISP.

Comment 33

[Justin Dolske [:Dolske]]

Hmm, I tried installing Norton and doing the steps in comment 29, but still can't get it to crash. I poked at it with XPCOMViewer, but it doesn't *seem* to override the default http handler (I should see a different CID next to the @mozilla.org/network/protocol;1?name=http, presumably).

Comment 34

[Christian :Biesinger (don't email me, ping me on IRC)]

Not necessarily. They might register their handler with the same CID.

You could check compreg.dat for an entry referencing norton.

Comment 35

[Damon Sicore (:damons)]

Any more progress here?  If we can get this into a beta, we should really do whatever we can to make it happen.

Comment 36

[Justin Dolske [:Dolske]]

Attachment: Patch v.2

I checked compreg.dat, but it doesn't look like Norton overrides the HTTP protocol handler. Maybe it was only a problem in an earlier Norton update? I can't reproduce the problem on an unpatched build, so that's possible.

I changed GetProtocolFlags to just share a common #define as we discussed. Still need a null check in NewChannel, though [or some other defense]... Most of the crash stacks involve nsIOService::NewChannelFromURI(), which calls handler->NewChannel() after handler->GetProtocolFlags().

Not sure what else to do to reproduce the problem to understand this more fully, so seems like we should at least take this to wallpaper over whatever's happening.

Comment 37

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 410622 [details] [diff] [review]
Patch v.2

 nsHttpsHandler::NewChannel(nsIURI *aURI, nsIChannel **_retval)
 {
+    if (!gHttpHandler)


can you also an NS_ABORT_IF_FALSE here? this should not happen, really.

Comment 38

[Justin Dolske [:Dolske]]

Attachment: Patch v.3

With NS_ABORT_IF_FALSE.

Comment 39

[Justin Dolske [:Dolske]]

Pushed http://hg.mozilla.org/mozilla-central/rev/29b46a13af1a

Comment 40

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 410909 [details] [diff] [review]
Patch v.3

a192=beltzner

Comment 41

[Justin Dolske [:Dolske]]

Pushed to 192: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/ff93d3746275

Comment 42

[Daniel Veditz [:dveditz]]

Comment on attachment 410909 [details] [diff] [review]
Patch v.3

totally safe even though QA can't verify it other than by code inspection. Approved for 1.9.1.6, a=dveditz for release-drivers

Comment 43

[Justin Dolske [:Dolske]]

Pushed to 191: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/8afe5f2598a8

Comment 44

[Al Billings [:abillings - ex-MoCo]]

We'll see if the crash goes away after release.

Comment 45

[chris hofmann]

so far, so good.  more than 1.8+ million people ran firefox 3.5.6 in the first few hours after it was released with no crashes reported for nsHttpsHandler::GetProtocolFlags  

while 3.5.5 has been getting 95-170 crashes per day over the same period and the rest of Dec.-to-date.