Issue metadata
Sign in to add a comment
|
Random hang in High Sierra
Reported by
kalajc...@gmail.com,
Dec 4 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.70 Safari/537.36 Steps to reproduce the problem: It just happened randomly in macOS High Sierra. What is the expected behavior? What went wrong? Hang randomly in macOS high Sierra, several friends have the same issue like this. Crashed report ID: How much crashed? Whole browser Is it a problem with a plugin? No Did this work before? N/A Chrome version: 63.0.3239.70 Channel: beta OS Version: OS X 10.13.1 Flash Version:
,
Dec 4 2017
Thanks for the Apple crash log.
,
Dec 4 2017
,
Dec 6 2017
Same here.
,
Dec 6 2017
Thanks for reporting the issue. @ kalajchow-- Could you please provide us the steps reproduced the crash/hang and if any crash id in chrome://crashes for better traiging purpose. Thanks!
,
Dec 7 2017
@hdodda, it happened totally random(once in 1-2 days), it hangs, and have to force quit it, after the relaunch, chrome://crashes has nothing. Tried fresh install macOS, same.
,
Dec 7 2017
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 7 2017
[Mac triage] This looks legit. ekaramad@, this change seems to have introduced the possibility of deadlocks into TextInputClientMac: https://chromium.googlesource.com/chromium/src/+/aeb3c5c70a6ab7472e802d424c9c4a628e819283 …the new paths that early out don't call AfterRequest() to release the lock. Could you take a look or find a better owner? Thanks.
,
Dec 8 2017
Hmmm...thanks. This makes sense. I will take a look.
,
Dec 8 2017
SG ✨👍✨
,
Dec 9 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d3951ca4288b3d348a630027b659341a090800b0 commit d3951ca4288b3d348a630027b659341a090800b0 Author: Ehsan Karamad <ekaramad@chromium.org> Date: Sat Dec 09 15:50:22 2017 In TextInputClientMac do not acquire lock when no IPC is sent to a renderer Requests for character index and first rect for range are handled by sending an IPC to the renderer and using a lock to and condition to wait until the response comes back. It is however possible to delete the IPC and return early. In such cases we should not acquire the lock and should return from the methods immediately. Bug: 791594 Change-Id: I6f6c43189aa6a3e8ae4894d57f596025503e76c4 Reviewed-on: https://chromium-review.googlesource.com/818627 Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Commit-Queue: Ehsan Karamad <ekaramad@chromium.org> Cr-Commit-Position: refs/heads/master@{#522998} [modify] https://crrev.com/d3951ca4288b3d348a630027b659341a090800b0/content/browser/renderer_host/text_input_client_mac.mm
,
Dec 13 2017
@ekaramad-- Could you please help us with the steps to verify the issue , if it needs to be verified from TE End and that would help us in better triaging. Thanks!
,
Dec 13 2017
Unfortunately I can neither confirm the fix nor provide steps for reproducing the hangs. The fix in comment #11 might be the fix for this bug but I cannot confirm. I an only confirm that comment #11 is the fix for the threading mishap reported in comment #7.
,
Dec 18 2017
That change looks like it should fix the issue I saw in the crash report, so I'm going to mark this as fixed. If anyone runs into it again in newer versions of Chrome, definitely ping the bug. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by meh...@chromium.org
, Dec 4 2017