Issue metadata
Sign in to add a comment
|
Lots of slow/hung renderer processes in current Canary |
||||||||||||||||||||||
Issue descriptionVersion: 53.0.2781.0 (Official Build) canary (64-bit) OS: Mac OS X What steps will reproduce the problem? (1) Use Chrome (Gmail, Calendar in multiple tabs) for a few hours. What is the expected output? Expect not to see any dialog boxes related to "page not responding". What do you see instead? Several "page not responding" dialog boxes have popped up just today, after taking today's Canary update. There must be some regression within the past few days. about:crashes doesn't contain any useful information. Attached is a symbolized sample from the renderer process which was running GMail at the time the dialog was raised. It was gathered via: sample [pid] 10 -file sample.txt and then feeding the result through crsym/. There's no clear indication of what caused Chrome to report the tab as hung. In this case the renderer recovered several seconds later. A few times today Calendar was reported as being hung and the only workaround was to kill the tab's renderer. This is a serious regression. I'm not sure how to reproduce it reliably, and am not sure whether it's showing up in tests on the waterfall.
,
Jun 28 2016
also getting this on windows
,
Jun 28 2016
ee5f7a9600000000 is a hang on inbox
,
Jun 28 2016
points at https://codereview.webrtc.org/2035483003/
,
Jun 28 2016
,
Jun 28 2016
jochen, I'm afraid I don't follow you. What's pointing at https://codereview.webrtc.org/2035483003/
,
Jun 28 2016
terelius - I think jochen is talking about go/crash/ee5f7a9600000000
,
Jun 28 2016
#6 - You probably meant to use another status... Hopefully it was Untriaged. :)
,
Jun 28 2016
#7:\ Thanks, but I still don't understand how Chrome identifies what thread is hung. The RtcEventLogThread is supposed to write WebRTC debug events to a file. Since the page does not run any WebRTC PeerConnection, there isn't any events so the thread will sleep. This should be ok, right? Assuming that a bug caused the thread to sleep even though the event queue had events to be processed, it still wouldn't affect the renderer/rest of WebRTC. If the event queue is full when WebRTC wants to add another event, it would just LOG() an error message and drop the event. #8: Yes, sorry. I changed my mind in the middle of assigning the bug to myself.
,
Jun 28 2016
M53 is branching this week and will be promoted to Beta in July.Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix ASAP. Thank you.
,
Jun 29 2016
primiano@ encountered this using 53.0.2781.x on OS X. I failed to repro it using 53.0.2782.x on OS X despite trying last evening and this morning. Has anyone experienced problems using the latest canary?
,
Jun 29 2016
There is an existing bug (https://bugs.chromium.org/p/chromium/issues/detail?id=615090) filed against the hang detector. Could this be a duplicate of that bug?
,
Jun 29 2016
It's possible. I'll block the other bug on this one and leave it to the owner to duplicate. Not seeing this on 53.0.2782.0 (Official Build) canary (64-bit), but haven't checked the other bug to see if specific changes either went into the earlier canary or this one.
,
Jun 29 2016
This definitely doesn't look to me that it is the same as the hang detector (issue 615090). The other issue is where the main thread is completely idle and has no work; yet this one looks to me that we are dispatching some events in the stack trace aren't we? I don't think I'm the appropriate owner for this.
,
Jun 29 2016
I might have missed the opportunity to gather a stack while whatever triggered the hang detector was running. Anyway, this isn't reproducing any more on my machine. If you and others aren't seeing it either let's close it. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by gov...@chromium.org
, Jun 28 2016Labels: M-53