Busy wait waking up form suspend with two GUI users |
||||
Issue descriptionChrome Version : 59.0.3071.115 OS Version: DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS" DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 GOOGLE_CODENAME=trusty GOOGLE_ID=Goobuntu GOOGLE_RELEASE="14.04 201708TL3-2" GOOGLE_ROLE=laptop GOOGLE_TRACK=stable What steps will reproduce the problem? 1. Have two users logged on the GUI 2. Suspend 3. Wake up and unlock X for user1 4. Notice how Chrome for user2 is using at least one full CPU 5. Unlock user2, CPU usage goes back to normal levels This has being going on for a while (weeks, months). Sorry I only now got around to file a bug. It happens (almost?) all the time. This time (so don't know how representative) I investigated a bit, there were two processes using 1 CPU each. PID 23825 was stuck at futex(0x7ffd947cf6ec, FUTEX_WAIT_PRIVATE, 1, NULL) = 0 I don't understand enough to explain why it was using 100% CPU while waiting for a futex (another thread busy-waiting?). Thread 23849 instead was calling repeatedly gettid (always getting the same answer). Command line for 23825 (23849 is gone now...): 23825 tty6 Sl 42:18 /opt/google/chrome/chrome --type=renderer --field-trial-handle=1 --primordial-pipe-token=9876ACD75319B2B66B4031F6448C3BDE --lang=en-GB --enable-crash-reporter=045b0137-2402-4363-92b4-f84e78c46abf, --extension-process --enable-offline-auto-reload --enable-offline-auto-reload-visible-only --blink-settings=disallowFetchForDocWrittenScriptsInMainFrame=false,disallowFetchForDocWrittenScriptsInMainFrameOnSlowConnections=true --enable-pinch --num-raster-threads=2 --enable-main-frame-before-activation --content-image-texture-target=0,0,3553;0,1,3553;0,2,3553;0,3,3553;0,4,3553;0,5,3553;0,6,3553;0,7,3553;0,8,3553;0,9,3553;0,10,3553;0,11,3553;0,12,3553;0,13,3553;0,14,3553;0,15,3553;0,16,3553;1,0,3553;1,1,3553;1,2,3553;1,3,3553;1,4,3553;1,5,3553;1,6,3553;1,7,3553;1,8,3553;1,9,3553;1,10,3553;1,11,3553;1,12,3553;1,13,3553;1,14,3553;1,15,3553;1,16,3553;2,0,3553;2,1,3553;2,2,3553;2,3,3553;2,4,3553;2,5,3553;2,6,3553;2,7,3553;2,8,3553;2,9,3553;2,10,3553;2,11,3553;2,12,3553;2,13,3553;2,14,3553;2,15,3553;2,16,3553;3,0,3553;3,1,3553;3,2,3553;3,3,3553;3,4,3553;3,5,3553;3,6,3553;3,7,3553;3,8,3553;3,9,3553;3,10,3553;3,11,3553;3,12,3553;3,13,3553;3,14,3553;3,15,3553;3,16,3553;4,0,3553;4,1,3553;4,2,3553;4,3,3553;4,4,3553;4,5,3553;4,6,3553;4,7,3553;4,8,3553;4,9,3553;4,10,3553;4,11,3553;4,12,3553;4,13,3553;4,14,3553;4,15,3553;4,16,3553 --disable-accelerated-video-decode --disable-webrtc-hw-vp8-encoding --service-request-channel-token=9876ACD75319B2B66B4031F6448C3BDE --renderer-client-id=7535 --shared-files=v8_natives_data:100,v8_snapshot_data:101 UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
,
Nov 24 2017
maggiolo@ Could you please respond to comment #1
,
Nov 24 2017
Hi, sorry for missing the first update. Not sure if it was that version, but I've not seen this bug for a while now, so ok for me to close. Thank you
,
Nov 24 2017
Thank you for providing more feedback. Adding requester "pnangunoori@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
,
Nov 24 2017
Marking this issue as WontFix as per comment#3. |
||||
►
Sign in to add a comment |
||||
Comment 1 by pnangunoori@chromium.org
, Oct 6 2017Labels: Needs-Feedback