Browser crash is seen on hitting Enter key on USB permission overlay at 'permission.site'
Reported by
sans...@etouch.net,
Jun 21 2017
|
|||||
Issue descriptionChrome Version:60.0.3112.40(Official Build) 6de35395b27b983b671c777caa9a273017e80d62-refs/branch-heads/3112@{#412}-32/64 bit OS : Windows(7,8,10) Precondition: Enable #enable-experimental-web-platform-features from chrome://flags. Steps: 1. Freshly launch Chrome and remove person from switch person overlay (a default profile will open). 2. Now add a person from from switch person overlay and navigate to https://permission.site/ on newly added person 3. Click on 'USB' (Permission overlay opens and make sure focus ring is in Get help link) 4. Hit Enter key and observe Actual: Browser crash is seen Expected: Browser should not crash This is non-regression issue seen from M-55, since USB permission overlay was introduced in 55.0.2841.0 Crash ID: 1a6ef09808000000 (Local Crash ID: 56d7a5e1-1bfc-4333-ac51-f4878621f7ca) Note: Above issue is not seen on Mac and Linux OS.
,
Jun 21 2017
Android and Chrome OS have way fewer crashes, and the stack trace is completely different, so that seems like a different issue. The majority of Windows crashes reported on crash/ also have a slightly different stack trace as well, namely one that happens when trying to open Chrome while it's already running (eg. crash/656d744758000000). I don't have a fully reproduction for those though, so I'm going to look at the one for the USB chooser. GetBrowser() in usb_chooser_controller.cc calls ProfileManager::GetActiveUserProfile(), which is supposed to return "the" profile for the current user, but "the" profile is not a well-defined concept on multi-profile platforms, as there can be multiple profiles. What's more, the method returns the default profile, which might not even exist anymore on disk (but could still be around in memory if it has been removed in this browser session, because complicated reason). So, what seems to happen here is that this tries to open a new browser for the non-existing default profile, which then crashes when it's trying to look up profile metadata from the ProfileAttributesStorage. Assigning to juncai@, who added that code in r396492. The UsbChooserController is created with a RenderFrameHost, so it should be able to get the corresponding profile via GetProcess()->GetBrowserContext(). (And yes, ProfileManager::GetActiveUserProfile() should probably be Chrome-OS-only -- the concepts of "active user" and "primary user" seem pretty Chrome-OS-specific. Ash on other platforms isn't really a thing anymore, right?)
,
Jun 21 2017
Filed issue 735531 for the ProfileManager::GetPrimaryUserProfile() and GetActiveUserProfile() cleanup.
,
Jun 26 2017
Is ProfileManager::GetLastUsedProfileAllowedByPolicy() more appropriate? Intuitively we should be able to keep a pointer to the Profile associated with the RenderFrameHost we are processing a request for but anecdotally any long-lived raw pointer to objects like Profile is dangerous. Is there any effort underway to use WeakPtr more widely for this?
,
Jun 26 2017
In this particular case, holding a pointer to the Profile object is totally fine. The Profile owns every WebContents and anything underneath that, and all of that is going to be destroyed before the Profile.
,
Jun 27 2017
Hard to get to crash, but still a crash. I've moved this to top of device team's backlog.
,
Jun 27 2017
,
Jun 29 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ed23c1c3b4a0bd7346088e790917daf31bbe2180 commit ed23c1c3b4a0bd7346088e790917daf31bbe2180 Author: Jun Cai <juncai@chromium.org> Date: Thu Jun 29 17:04:56 2017 Fix opening WebUSB chooser when user profile changes The "Get help" link uses ProfileManager::GetActiveUserProfile() to open a new tab for help page, and it causes the issue when the active user profile is removed or another user profile is created. This CL fixes it by using ProfileManager::GetLastUsedProfileAllowedByPolicy(). Bug: 735353 , 735360 Change-Id: I2b1989152cac8e698c7258920a2a401159eb6c50 Reviewed-on: https://chromium-review.googlesource.com/553725 Reviewed-by: Reilly Grant <reillyg@chromium.org> Commit-Queue: Jun Cai <juncai@chromium.org> Cr-Commit-Position: refs/heads/master@{#483399} [modify] https://crrev.com/ed23c1c3b4a0bd7346088e790917daf31bbe2180/chrome/browser/ui/bluetooth/bluetooth_chooser_controller.cc [modify] https://crrev.com/ed23c1c3b4a0bd7346088e790917daf31bbe2180/chrome/browser/usb/usb_chooser_controller.cc
,
Jun 30 2017
,
Apr 13 2018
I encountered same crash signature: ID d8dde741063384e7 What I did was creating a profile, removing it and almost instantly running Chrome from the "profile shortcut". Normally this creates a new profile but this once it crashed.
,
Apr 13 2018
Would you mind filing a new bug for that? Handling profile shortcuts should probably be treated differently. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ranjitkan@chromium.org
, Jun 21 2017Labels: Needs-triage OS-Android OS-Chrome
Status: Untriaged (was: Unconfirmed)