Same here on Canary, in debug.log just

[0623/214733.594:ERROR:process_info.cc(632)] range at 0x602b262200000000, size 0x1cc fully unreadable
[0623/214733.594:ERROR:process_info.cc(632)] range at 0x602b264200000000, size 0x1cc fully unreadable
[0623/214733.594:ERROR:process_info.cc(632)] range at 0x0, size 0x1cc fully unreadable

In Task Manager Chrome stays for ~1 minute and closes itself.

I also encountered this issue. Removing C:\Users\username\AppData\Local\Google\Chrome SxS\User Data allowed Canary to start up as expected.  I encountered this after installing the latest Canary update on Win10 (not a fresh install).

It looks like this is happening whenever you close 61.0.3139.0 on Windows 10. So to be clear:

1) Install 61.0.3139.0 on Win10
2) Launch Chrome
3) Close Chrome
4) Attempt to restart Chrome -> doesn't work

The work around is going into C:\Users\%USERNAME%\AppData\Local\Google\Chrome SxS\User Data\Local State and deleting the extremely long variations_compressed_seed value.

I think I encountered this - Canary crashed as I was using it, and then it wouldn't launch anymore. I restarted my computer but Canary still won't launch.

This appears to be resolved with Canary 61.0.3139.4

Hello, I am the originator of this bug, which was filed on my behalf. I am commenting so that I hopefully get email notifications (I can't find a setting for that on here). I would also like to point out that this is affecting about half of the Windows 10 computers we have rolled out. We have actually stopped rolling out new computers because of this. The odd thing is that it is affecting all of the secretaries, but not the administrators. There is absolutely no difference in the computers or rights/policies. The only thing is that the secretaries use their computers more heavily, and use Skyward more heavily. This needs to be fixed as soon as possible for us. I have a copy of a borked profile user data, so I can now reproduce the issue on another computer, although I cannot reproduce what is causing the profile to be corrupt.

Adding some people who might have an idea based on blame's of related code 

Also this seems as a pretty bad issue to me to deserve P1 rating.

Re c#6: Just fyi, you can click the star on the top left (right next to the issue number to follow an issue). Commenting should do the trick too. :)

Yeah, that's not good.  This probably is either lazyboy@ or myself (we've both been making changes to extension events recently).  It looks like filtered events are being stored excessively.  A couple questions:
- Are there repro steps?  You mentioned that you've copied the bad file, but it would help to be able to reproduce the bug that caused the bad state in order to debug/test.
- Can you attach the full file (if there's no significant PII) or provide a full snippet?  In particular, looking at the entries,
> "filtered_events":{"chromeWebViewInternal.onContextMenuShow":[{"instanceId":1}
> "guestViewInternal.onResize":[{"instanceId":637}

These are invalid JSON, so (I'm assuming) there's extra data there missing.  Seeing a bit more of the big picture would help.

I have attached the offending profile file, with references of the user id removed. 

I am not able to reproduce what is causing the profile to become corrupt. It is happening too randomly. All I can say for sure is that the issue is always first thing in the morning when they start Chrome. It is as if it did not shut down correctly the day before.

Deleted: Preferences-broken-removed-profile-info 350 KB

Preferences-broken-removed-profile-info 350 KB View Download

Thanks!

I'm looking into this, and will update as I find more information.

First notes:
* There's only one extension that seems to be affected here, which is hangouts.
  * It is registered for event listeners in 23 different filtered events, 22 of which have 616 listeners (with different instanceIds); this is a total of 13552 listeners.  That's... bad.
* I'm not sure if something changed in chrome or in hangouts; either way, this shouldn't be possible in chrome and we should fix it.

More information:

webview events are extension events under the hood.  When a listener is attached, we silently add a filter to them so that when we dispatch the event, it only goes to that webview.

https://chromium.googlesource.com/chromium/src/+/868a94beaaa07d23125c241ef9f83ba4fa330fb8/extensions/renderer/resources/guest_view/guest_view_events.js#107

However, when a lazy event listener is registered, we store the information in the preferences file (so we know what events are being listened for and can know when to wake up the event page).  With filtered events, this means that every time a different filter is added, we update it.

This means that each time a listener is added to a webview event, we end up adding a new filter to that event.  Every time the event page is torn down and set up, the webview instance ids will be different.  So storing them in prefs is very unhelpful.

My instinct would be that we shouldn't allow webview event listeners to be lazy, for this reason.  This would address that concern.  However, there *may* be another risk here: if hangouts opens a webview in a different window, and that window outlives the event page, then the event page wouldn't be woken up when something happens to that webview.

paulmeyer@, lazyboy@, y'all know webview event stuff better than I; any thoughts here?

I had a laptop with Win 1703 and several versions of Chrome that drove me crazy trying to figure this freezing out.  Never did find exactly what was causing it, usually run with several tabs open, gmail, Google Voice, etc but one time it froze with just news.google open.
 
Downloaded canary ver. 61.0.3141.0, renamed the default folder in appdata, life is good.  I' convinced it is the Win 1703 Creator version that started this issue.

Dang, hangouts, I should have known!!! A few months ago or so I was having an issue on my Win7 32bit computer where chrome would munch on cpu for no reason. It took me a few weeks to figure it out, but it was (insert drum roll here) hangouts! I removed it from our IT group in the admin console and all was good after that.

We originally added hangouts to certain groups so they had an option for interoffice messaging. We since upgraded our phone system and now use its messaging software. I don't think anyone actually uses hangouts, so I think it is going bye-bye. If that is cause, that means that any fix that is done to chrome may very well not be noticed by us since we will remove hangouts in the admin console.

I still have the full google local appdata from a corrupt profile if any more information is needed. But is sounds like you guys already have a plan to fix this. I am happy that I could provide good information on the issue to trigger a proper fix.

Just went into the admin console and checked, and sure enough, the secretaries group had hangouts installed. That explains why they had issues but the administrators did not. It was set to force install, and I just changed that, so hopefully no more issues. Thanks for pointing me in the right direction. I hope that I have provided good information about getting it fixed properly.

Yep, thanks a bunch for the info, sdwyer@!  The profile should be really helpful in diagnosing this further, if necessary.

It looks like hangouts is the immediate cause here, but I'm hopeful that we can address this chrome-side to make sure it doesn't happen again.

pastmarovj@, do you have any other reports of this?  Do we know how widespread it is?  (If this is fairly isolated, we should fix it, but it's less of a fire.  If this happened to 100% of hangouts users... that'd be bad - especially if this isn't a regression, in which case it could affect users on stable.)

rdevlin@, in regards to your comment about affecting users on stable, we ARE using the stable version of Chrome. The issue was noticed with the last version of 58, and when 59 just recently came out the issue persisted. But there is another possible factor here. I had an issue with hangouts months ago on a win7 32bit computer, and now this recent issue that spawned this bug report. There is one thing in common, hangouts was being force installed at the group level in the admin console, even though it was not being used by the end user. Maybe that is the smoking gun. I can't imagine that an issue like this with hangouts would not be noticed by others by now. Unless almost no one is using hangouts...

Removing myself as this untriaged now.  Is this bug related to the profiles code?

Yeah I don't know why this bug was assigned to you when devlin already confirmed he was looking into that. I am assigning the bug to him now to avoid confusion.

FYI, to fix this, we're planning on not letting webview events have lazy listeners registered.  This should have always been the case, since
a) webview events are only implemented as extension events as an implementation detail, and don't themselves have any concept of laziness; and
b) webview events are tied to a specific webview, so when the webview is destroyed, there should be no chance that the extension is ever notified of that event.  Since lazy listeners could only be registered to webview events in the same process, this fundamentally means that webview events should never be able to be used to wake up an extension/app.

+ivaylobakalov@ as FYI, and in case there are any hangouts concerns.

s/ivaylobakalov/gregburgess

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/91f0c8a3cc9d78c32e914b74c920c26ccd748968

commit 91f0c8a3cc9d78c32e914b74c920c26ccd748968
Author: rdevlin.cronin <rdevlin.cronin@chromium.org>
Date: Wed Jul 19 21:26:33 2017

[Extensions Bindings] Introduce a supportsLazyListeners property

Right now, we determine whether to store the record of a lazy listener
in the extension prefs based only on the type of context - if the
context registering the listener is a lazy context (like an event page),
then we store a lazy listener in extension prefs.

This is incorrect for webview events.  Webview events are exposed on a
<webview> DOM object, but are implemented behind-the-scenes as
extension events (including the listener bookkeeping). However, having a
lazy listener for a webview event doesn't make sense:
- the only time a listener would be considered lazy is when the listener
  was added in a lazy context
- a lazy listener will only be used to wake up an inactive context
- webview events are tied to a specific webview
Thus, a lazy listener would only be used for a webview which has since
been torn down.

With this in mind, we can avoid registering any lazy listeners for
webview-related events. Introduce the key supportsLazyListeners into the
JSON schema and add it for webview events. When this key is present,
events don't register lazy listeners.

Wire this up for both native and JS-based bindings, and add unit tests
for the bindings and an end-to-end test to ensure that webview event
listeners will never be registered as lazy listeners.

A followup will add logic to clean up current prefs to remove traces of
the listeners.

BUG= 736381 

Review-Url: https://codereview.chromium.org/2973903002
Cr-Commit-Position: refs/heads/master@{#487991}

[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/chrome/browser/extensions/events_apitest.cc
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/chrome/common/extensions/api/webview_tag.json
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/chrome/renderer/resources/extensions/web_view/chrome_web_view.js
[add] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/chrome/test/data/extensions/api_test/events/webview_events/manifest.json
[add] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/chrome/test/data/extensions/api_test/events/webview_events/test.js
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/browser/event_router.cc
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/browser/event_router.h
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/bindings/api_binding.cc
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/bindings/api_binding_js_util.cc
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/bindings/api_binding_js_util.h
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/bindings/api_event_handler.cc
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/bindings/api_event_handler.h
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/bindings/api_event_handler_unittest.cc
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/bindings/api_event_listeners.cc
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/bindings/api_event_listeners.h
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/bindings/api_event_listeners_unittest.cc
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/bindings/event_emitter_unittest.cc
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/chrome_setting.cc
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/event_bindings.cc
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/event_bindings.h
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/native_extension_bindings_system.cc
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/resources/app_window_custom_bindings.js
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/resources/context_menus_handlers.js
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/resources/event.js
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/resources/guest_view/guest_view_events.js
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/resources/guest_view/web_view/web_view_events.js
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/resources/messaging.js
[modify] https://crrev.com/91f0c8a3cc9d78c32e914b74c920c26ccd748968/extensions/renderer/resources/web_request_event.js

There are two other pieces that we should still do here:
- ensure webview-related events are properly removed
- remove any stored lazy webview events

I'm going to file separate bugs for those and close this one out.

New issues are issue 754799 and issue 754800.