Accessing settings/content occasionally crashes
Reported by
ke...@vcsjones.com,
Dec 25 2016
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/602.3.12 (KHTML, like Gecko) Version/10.0.2 Safari/602.3.12 Steps to reproduce the problem: 1. Open a site that has a bad certificate. 2. Click the red triangle in the address bar 3. Click site settings What is the expected behavior? The site settings tab opens successfully What went wrong? It occasionally crashes. Sometimes more frequently than not. Crashed report ID: No How much crashed? Just one tab Is it a problem with a plugin? No Did this work before? N/A Chrome version: 55.0.2883.95 Channel: stable OS Version: OS X 10.12.2 Flash Version: 23.0.0.207 There are zero reported crashes in "chrome://crashes". I don't know if the invalid certificate is related or not, but that's how I found this. It never crashes if I open it by navigating directly to "chrome://settings/content". Only from then "Site Settings" button. The client_id2 in Local State is 997845fc-0a1d-4114-8361-0ceac0c736c7.
,
Dec 27 2016
It sounds like there are two issues: the crash itself, and then nothing being reported in chrome://crashes. +mark for crashpad, and Proj-MaterialDesign-WebUI.
,
Dec 28 2016
Anything in ~/Library/Logs/DiagnosticReports for Google Chrome or crashpad_handler at about the time of the crash?
,
Dec 28 2016
,
Dec 29 2016
@mark No. That directory is empty. I double checked that "Automatically send usage statistics and crash reports to Google" is enabled in settings, and reproduced the crash again for good measure, and nothing appeared in the directory or "chrome://crashes". I don't have anything installed, to my knowledge, that would do this. No AV, no weird disk cleanup utilities, etc. It's mostly a stock macOS install with a few productivity apps. The only Chrome extension installed that doesn't ship with the browser is Google's Lighthouse.
,
Dec 29 2016
They’re not really crashes in the pure sense, then. That’d make this similar to bug 674981 . How reproducible is this?
,
Dec 29 2016
@mark I can reproduce it 1/5 times(ish) as seen in the video in the original bug. 674981 appears to be restricted.
,
Jan 3 2017
674981 wasn’t interesting aside from it being another case of “dead renderer, no crash report.” There was nothing sensitive there, so I de-restricted it. I couldn’t reproduce this bug after 15 tries on each of https://expired.badssl.com/ and https://self-signed.badssl.com/. Kevin, can you reproduce the bug with either of those sites?
,
Jan 11 2017
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 12 2017
,
Jan 13 2017
Still waiting for response from reporter to c#8.
,
Jan 13 2017
In addition to the question from comment 8: I had asked in comment 3 about reports showing up in the user-level ~/Library/Logs/DiagnosticReports. Can you also check for reports in the root-level /Library/Logs/DiagnosticReports?
,
Feb 13 2017
Gentle ping to get an update from the reporter as per C#3 and C#8.
,
Feb 18 2017
No response from original reporter for over 30 days so closing out. Happy to reopen with answers to c#8 and c#12. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by schenney@chromium.org
, Dec 26 2016