On 11/16/2012 1:11 PM, Benjamin Smedberg wrote:
> The Windows 64-bit builds are a constant source of misunderstanding and
> frustration, at least in the following ways:
>
> * Many plugins are not available in 64-bit versions
> * The plugins that are available don't work correctly in Firefox because
> we haven't implemented things like windowproc hooking, which means that
> hangs are more common
Video driver / graphics issues on 64bit systems ranks pretty high too, no?
With 64bit an several addons, flash, etc I haven't experienced the
instability you describe over the last 6 months. In the 6 months prior
there was instability, but not 64bit specific. OTOH, I may not be a
typical trunk user - I am not normally doing lots of flash, facebook,
etc, on my 64bit instance.
> * Crashes submitted by 64-bit users are currently not high priority
> because we are working on other things.
I assume you mean 64bit windows - and don't see why anyone would have a
problem with that. It's just reasonable triaging.
So what has mainly prompted the change in thinking? Have 64bit
crashes+hangs gotten worse recently? Or are we mainly just hitting more
workflow issues in Socorro (mentioned below) or elsewhere?
> ** This is frustrating for users because they feel (and are!) second-class.
I am not sure I see the frustration you suggest reflected in our bug
reports [1] - it doesn't seem disproportionate. Besides, when running
trunk users implicitly sign up to be broken in every possible way.
[1] "64bit" bugs with activity in past year
http://tinyurl.com/cmjjpue
> ** It is also frustrating for stability team triage because crash-stats
> does not easily distinguish between 32-bit and 64-bit builds in the
> topcrash lists and other reports. We basically ignore a set of nightly
> "topcrashes" because they are 64-bit only. (See bug 811051).
This frustration I can perhaps sympathize with. However, we routinely
ignore some signatures for various reasons - caused by AV, malware,
addons, etc. So how is 64bit crashes different from these, and what
quantity of top 30 crashes or top 100 crashes are we talking about?
Also, bug 811051 doesn't identify the crashes/examples being implicated.
Is #2 FF19 crash an example?
https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A19.0a1&query_search=signature&query_type=contains&reason_type=contains&date=11%2F19%2F2012%2023%3A46%3A28&range_value=2&range_unit=days&hang_type=any&process_type=any&do_query=1&admin=1&signature=nsHttpConnection%3A%3ASetSecurityCallbacks%28nsIInterfaceRequestor*%29
- the bug report indicates fixed but doesn't indicate a specific
connection to 64bit.
> For these reasons, I would like to propose that we disable the 64-bit
> Windows nightly builds. We should publish a custom update to move
> current win64 nightly users back onto win32.
might it be sufficient to disable crash reporter by default in 64bit builds?
> I also think we should consider disabling the win64 builders completely,
> but I'm also willing to shelve that proposal for another time if it is
> controversial. If we *don't* disable win64 hourlies, I plan on adding
> --disable-plugins to their configuration.
You might want to initially only do the later, in case the win64
question is revisited in the future.
datapoint - I first turned to 64bit builds about a year ago because the
32bit builds couldn't handle the number of windows and tabs I was using.
That's the only reason I can think of that would require a user to need
64bit on windows. And memshrink has made a dent in reducing that need.
Having said all the above, if the odds are slim to none of us ever
releasing 64 bit windows build with the current code base, then I think
the bottom line here is there is little no long term value to providing
said builds and it just fuels speculation and questions of "when are
they ever going to release 64bit on window?"
But if the odds are more than slim, then perhaps we want to keep them
available for people to use, and continue to be OK with 64bit windows
bug reports not getting the same level of attention that other bugs get.