A few weeks ago, I noticed Chrome Canary 64-bit would either refuse to launch (a window) or would launch as Not Responding in Windows. When I opened Task Manager to kill Canary, though, I saw this:
Canary had 32-bit processes, despite the 64-bit installation. At first I figured I’d either absent mindedly installed the 32-bit build or forgotten to switch over to the 64-bit build when it first became available, so I reinstalled the 64-bit build in-place.
That fixed the problem for a few days until it returned. At this point I knew for sure the error wasn’t my doing, so I filed a bug.
Turns out Google deliberately pushes 32-bit builds to 64-bit installs on high RAM – apparently ≥ 8GB, from my experience – machines to find memory-related bugs. From 2 developers in that bug thread:
On occasion, we send a 32-bit build to 64-bit installs. The most frequent case is an ASAN build to help us find memory-related bugs in Chrome. It’s most likely that you received one of these build (chrome://version will tell you), and that you’d be back to 64-bit canary the next day.
Some background: We’ve recently started shipping ASAN instrumented builds of Chrome to canary users. These builds contain instrumentation that track down heap memory errors, and provide extremely useful bug reports to Chrome developers. As grt@ mentions, if you’re on one of these builds you’ll see a ‘SyzyASan’ label if you navigate to chrome://version.
– To limit user pain we filter for machines with sufficient memory, as there is a significant memory overhead to the instrumentation.
– To further limit user pain we randomly select 1 in every 20 users every day. That is, for any day’s update you have a 1 in 20 chance of receiving an ASAN instrumented build. The next days update still has the same 1 in 20 chance, so most often you should end up back on a non-instrumented build.
– Unfortunately, the technology is 32-bit only right now. In order to increase the audience of potential users we also ship to 64-bit users, intentionally downgrading them to 32-bit builds for a day.
We are working on making the instrumentation work natively in 64-bit mode, but that is at least 6 months away.
Finally, if the instrumentation is rendering your browser completely unusable we do have an opt-out mechanism in place.
I’ll let you decide the morality of pushing broken 32-bit builds to 64-bit users, but at least we have an answer.
Currently the only fix I know of is an in-place reinstall.