Issue metadata
Sign in to add a comment
|
Chrome unusable once again after a few days of inactivity |
|||||||||||||||||||||||||||||||
Issue descriptionChrome unusable once again after a few days of inactivity. Similar symptoms as before. Physical footprint: 1.1G Physical footprint (peak): 27.2G Was spinning at 100%+ cpu for a while. Eventually became useable again. Here's a sample while it was busy.
,
Sep 17
Here's a memory internals dump.
,
Sep 17
The sample seems to clearly point to an issue with sampling profiler
,
Sep 17
This is a known issue -- we need to adjust the sample scheduling to avoid this problem.
,
Sep 17
Is "Physical footprint (peak): 27.2G" also explained by sampling profiler?
,
Sep 17
It's not. Per OOPHP/memlog the largest allocations from the sampling profiler are under 100MB.
,
Sep 17
> the largest allocations from the sampling profiler are under 100MB Those are live allocations, not peak allocations. Given that sampling profiler is causing CPU churn for some period of time, it's possible that this is also causing a temporary spike in memory usage.
,
Sep 17
The largest values seen by OOPHP are due to metrics code retaining large numbers of saved profiles pending an opportunity to upload, so are effectively peak allocations. The profiler doesn't use significantly more memory per profile while active than it does for saved profiles, so it seems unlikely that it could be responsible for more than a tiny fraction of the peak footprint.
,
Sep 17
asvitkine: Unfortunately, the heap dump you uploaded in c#2 does not have any allocations. Can you enable the following two flags in chrome://flags so that we can tell if this issue happens in the future? wittman: The values seen by OOPHP are for steady-state memory consumption. In this case, I suspect there's a brief, large spike in memory usage, which then quiesces, so we wouldn't expect to see this in OOPHP reports.
,
Sep 17
In this case the profiler should be using at most ~1MB for transient allocations in the browser process. It's highly unlikely there's a latent bug causing four orders of magnitude larger memory usage than expected that we've only just discovered.
,
Sep 18
Added those flags. This morning: Physical footprint: 624.8M Physical footprint (peak): 2.6G Adding memory internals dump.
,
Sep 24
Given the discussion here, it's not obvious that sampling profiler is the only cause. So I'm going to unmark this bug as a duplicate of the other and instead make it blocked on it. When the other bug is resolved, we can check the behavior here. For reference, I'm still experiencing this issue every morning when I unlock my desktop Mac. So I have to use my laptop for the first 30 mins in the office.
,
Sep 24
Currently my Chrome footprint is 85G. And it's spinning at 100% CPU. I did enable the memory flags before, but Chrome hasn't recovered to useable state yet so I can't provide a memlog. Did the memlog from comment 11 look useful? Erik, I'm assigning back to you since part of the issue here is indeed the high RAM use which wittman@ does not believe is related to sampling profiler.
,
Sep 24
Can you grab a CPU sample? If we can repro this issue without seeing the CPU spinning 100% dealing with sampling profiler, then I'll look into it.
,
Sep 24
Thanks.
The main thread appears to have an endless stream of work queued up.
Half the time is spent in:
mojo::core::ports::MessageQueue::GetNextMessage and
The other half in:
"""
+ ! : 990 mojo::Connector::ReadSingleMessage(unsigned int*) (in Google Chrome Framework) load address 0x104be6000 + 0x258a4aa [connector.cc:458]
+ ! : | 976 mojo::internal::MultiplexRouter::Accept(mojo::Message*) (in Google Chrome Framework) load address 0x104be6000 + 0x2590234 [multiplex_router.cc:594]
+ ! : | + 690 mojo::internal::MultiplexRouter::ProcessIncomingMessage(mojo::internal::MultiplexRouter::MessageWrapper*, mojo::internal::MultiplexRouter::ClientCallBehavior, base::SequencedTaskRunner*) (in Google Chrome Framework) load address 0x104be6000 + 0x2590a2b [multiplex_router.cc:869]
+ ! : | + ! 655 viz::mojom::CompositorFrameSinkClientStubDispatch::Accept(viz::mojom::CompositorFrameSinkClient*, mojo::Message*) (in Google Chrome Framework) load address 0x104be6000 + 0x969cfa [compositor_frame_sink.mojom.cc:1454]
+ ! : | + ! : 614 cc::mojo_embedder::AsyncLayerTreeFrameSink::OnBeginFrame(viz::BeginFrameArgs const&) (in Google Chrome Framework) load address 0x104be6000 + 0x4533fc9 [trace_event.h:1106]
+ ! : | + ! : | 554 viz::ExternalBeginFrameSource::OnBeginFrame(viz::BeginFrameArgs const&) (in Google Chrome Framework) load address 0x104be6000 + 0x371733c [begin_frame_source.cc:0]
+ ! : | + ! : | + 552 viz::BeginFrameObserverBase::OnBeginFrame(viz::BeginFrameArgs const&) (in Google Chrome Framework) load address 0x104be6000 + 0x3715353 [begin_frame_source.cc:67]
+ ! : | + ! : | + ! 518 cc::Scheduler::OnBeginFrameDerivedImpl(viz::BeginFrameArgs const&) (in Google Chrome Framework) load address 0x104be6000 + 0x37d7767 [auto_reset.h:32]
+ ! : | + ! : | + ! : 508 cc::mojo_embedder::AsyncLayerTreeFrameSink::DidNotProduceFrame(viz::BeginFrameAck const&) (in Google Chrome Framework) load address 0x104be6000 + 0x4533ce5 [vector:1719]
+ ! : | + ! : | + ! : | 390 viz::mojom::CompositorFrameSinkProxy::DidNotProduceFrame(viz::BeginFrameAck const&) (in Google Chrome Framework) load address 0x104be6000 + 0x96818b [compositor_frame_sink.mojom.cc:379]
+ ! : | + ! : | + ! : | + 379 mojo::Connector::Accept(mojo::Message*) (in Google Chrome Framework) load address 0x104be6000 + 0x258a883 [message_pipe.h:97]
+ ! : | + ! : | + ! : | + ! 363 mojo::core::Core::WriteMessage(unsigned int, unsigned long, MojoWriteMessageOptions const*) (in Google Chrome Framework) load address 0x104be6000 + 0x9b6d6f [core.cc:572]
+ ! : | + ! : | + ! : | + ! : 363 mojo::core::MessagePipeDispatcher::WriteMessage(std::__1::unique_ptr<mojo::core::ports::UserMessageEvent, std::__1::default_delete<mojo::core::ports::UserMessageEvent> >) (in Google Chrome Framework) load address 0x104be6000 + 0x9c12e4 [message_pipe_dispatcher.cc:143]
+ ! : | + ! : | + ! : | + ! : 362 mojo::core::NodeController::SendUserMessage(mojo::core::ports::PortRef const&, std::__1::unique_ptr<mojo::core::ports::UserMessageEvent, std::__1::default_delete<mojo::core::ports::UserMessageEvent> >) (in Google Chrome Framework) load address 0x104be6000 + 0x9c5de1 [node_controller.cc:257]
+ ! : | + ! : | + ! : | + ! : | 359 mojo::core::ports::Node::SendUserMessage(mojo::core::ports::PortRef const&, std::__1::unique_ptr<mojo::core::ports::UserMessageEvent, std::__1::default_delete<mojo::core::ports::UserMessageEvent> >) (in Google Chrome Framework) load address 0x104be6000 + 0x3d316d0 [node.cc:0]
+ ! : | + ! : | + ! : | + ! : | + 347 mojo::core::ports::Node::SendUserMessageInternal(mojo::core::ports::PortRef const&, std::__1::unique_ptr<mojo::core::ports::UserMessageEvent, std::__1::default_delete<mojo::core::ports::UserMessageEvent> >*) (in Google Chrome Framework) load address 0x104be6000 + 0x3d3185b [memory:2631]
+ ! : | + ! : | + ! : | + ! : | + ! 343 mojo::core::NodeController::ForwardEvent(mojo::core::ports::NodeName const&, std::__1::unique_ptr<mojo::core::ports::Event, std::__1::default_delete<mojo::core::ports::Event> >) (in Google Chrome Framework) load address 0x104be6000 + 0x9c7927 [memory:2631]
+ ! : | + ! : | + ! : | + ! : | + ! : 302 mojo::core::NodeController::SendPeerEvent(mojo::core::ports::NodeName const&, std::__1::unique_ptr<mojo::core::ports::Event, std::__1::default_delete<mojo::core::ports::Event> >) (in Google Chrome Framework) load address 0x104be6000 + 0x9c7216 [memory:2631]
+ ! : | + ! : | + ! : | + ! : | + ! : | 299 mojo::core::NodeChannel::SendChannelMessage(std::__1::unique_ptr<mojo::core::Channel::Message, std::__1::default_delete<mojo::core::Channel::Message> >) (in Google Chrome Framework) load address 0x104be6000 + 0x9c2cab [memory:2631]
+ ! : | + ! : | + ! : | + ! : | + ! : | + 246 mojo::core::(anonymous namespace)::ChannelPosix::Write(std::__1::unique_ptr<mojo::core::Channel::Message, std::__1::default_delete<mojo::core::Channel::Message> >) (in Google Chrome Framework) load address 0x104be6000 + 0x9d47fd [channel_posix.cc:168]
+ ! : | + ! : | + ! : | + ! : | + ! : | + ! 236 mojo::core::(anonymous namespace)::ChannelPosix::WriteNoLock(mojo::core::(anonymous namespace)::MessageView) (in Google Chrome Framework) load address 0x104be6000 + 0x9d6a6a [channel_posix.cc:0]
+ ! : | + ! : | + ! : | + ! : | + ! : | + ! : 234 mojo::SocketWrite(int, void const*, unsigned long) (in Google Chrome Framework) load address 0x104be6000 + 0x25a33ee [socket_utils_posix.cc:84]
+ ! : | + ! : | + ! : | + ! : | + ! : | + ! : | 234 write (in libsystem_kernel.dylib) + 10,0 [0x7fff6ec3b6fa,0x7fff6ec3b6f0]
"""
Looks like a viz bug where failure to produce frames results in infinite loop.
Raising priority since this is causing Chroem to be unusable.
,
Sep 24
After lunch, Chrome became useable again and memory use stabilized at 2G for browser process, from the 80G it was using before (I guess a lot of the 80G was all the graphics queued updates?). 2G is still a lot, so here's a memlog for diagnosis (with the two about flags enabled as suggested by Erik).
,
Sep 24
Thanks, filed: https://bugs.chromium.org/p/chromium/issues/detail?id=888665
,
Sep 30
This stack trace in #16 does not make sense to me. DidNotProduceFrame does not call OnBeginFrame. Anyone have repro steps?
,
Oct 1
fsamuel: The stack goes the other way: OnBeginFrame calls DidNotProduceFrame. Something is sending an [almost] endless stream of messages to the browser, causing half of CPU time to be spent in mojo::core::ports::MessageQueue::GetNextMessage, and the other half to be spent in OnBeginFrame. Given the latter, this suggests that these are BeginFrame messages.
,
Oct 10
+ccameron@ So given this is in the browser, then it seems like something on Mac is requesting BeginFrames and then never stops requesting BeginFrames. Then again, it was initially suggested maybe there's a memory leak. One possibility is a continuous stream of new LocalSurfaceIds allocated? I'm not sure we can get into this state but I'm not super familiar with MacViews code.
,
Oct 10
This continues to happen every day for me, so let me know if there's any diagnostic info you need me to provide (although I provided a lot already.) Given the severity of the symptoms, I'm marking RBS M70.
,
Oct 10
Changing to M71 which is what's branching this week (and we'll have time to merge to before stable if fixed in m72.)
,
Oct 10
asvitkine, could you attach the variations from about:version? I'm curious about the VizDisplayCompositor? Also, see if anything changes if you manually enable or disable VizDisplayCompositor in about:flags.
,
Oct 10
VizDisplayCompositor-Control - do you still want me to try toggling it, given its in Control group?
,
Oct 10
Ohh this bug isn't what I thought it was then! Very strange. This is coming from the renderer. I wonder if this is a site isolation bug where off screen OOPIFs are continually pumping CompositorFrames.
,
Oct 10
Umm, sure, just to see if it makes the issue ago away (wouldn't be the first time). fsamuel@ given #25, is there another direction we should take this?
,
Oct 15
Friendly ping to get an update as it si marked as RBS. Thanks..!
,
Oct 15
Shifting based on #27
,
Oct 18
My Chrome has been frozen for a few days now on my desktop. (I just used my laptop ... and kept the session up so we can debug if needed.) Here are a few samples - one from yesterday and another from today. Chrome is in same state - browser process frozen at 100% cpu and a child process also at 100% cpu. Samples from browser process from 17th and 18th and of child process from 18th. Will likely need to kill the session today as I'm moving desks.
,
Oct 18
At this point, the machine appears to be entirely hosed by thrashing. I would guess that if you ran "vm_stat" from the command line or took a screenshot of the activity monitor memory tab, you'd see terrifying memory usage. We have a heap dump that indicates that this is related to the compositing system [non-viz]. We'll need a graphics expert to investigate.
,
Oct 19
ccameron@ or kbr@, can one of you peek at the heap dump?
,
Oct 19
Compositing experts enne@ or danakj@ would be better individuals to take a first look.
,
Oct 19
Sorry, I'm not sure what you want me to look at. If by heap dump, you mean the trace from comment #18, it looks like the biggest memory offender is the browser process, with 2gb of memory. Everything else is in the 400mb range. I'm not sure what is meant by erikchen's comment in #31 about this being related to non-viz. Given that this is only seems to be happening to asviktine, it makes me wonder what is special here. Maybe some extension? Does a profile without extensions have this same problem?
,
Oct 19
jam@, based on the profile in comment #30 sample_child_18th.txt it looks like a renderer is spinning on content::mojom::RenderFrameMessageFilterProxy::GetCookies(). Does anything stand out to you?
,
Oct 19
It's hard to say, e.g. is a page making many cookie requests, is the disk slow, is the cookie store corrupt? When this happens, is there a Network Service in the Chrome task manager? If so, can you disable network-service in about:flags to see if it goes away?
,
Oct 20
Today I had a different flavor of what also looks like an OOPIF related browser hang on 69.0.3497.100. Sample profile attached. It was while doing a find in page. Just looking at FrameTreeNode::GetSibling() iteration, if RenderFrameHostImpl::children _ had any duplicates (same FrameTreeNode added twice) we would get in an endless loop. Is this possible?
,
Oct 20
One main thing about my use case is I keep the machine awake (a desktop) with the screen locked for long periods of time. (E.g. the machine is not set to to go to sleep after a while), so if this behaviour ends up triggering bad behavior...
,
Oct 21
I was actually able to provoke the "find in page" hang for a 2nd time while interacting with the same site for a while at https://www.att.com/shop/u-verse/offers.html. I'll try to narrow it down.
,
Oct 21
I've filed the issue in #37 & #39 separately as Issue 897465 .
,
Oct 22
The sample in #41 shows that both the IO thread and Thread_3011 (whatever that is) are both basically stuck in mojo::core::ports::SinglePortLocker::SinglePortLocker(). It's hard to tell whether this is a) extremely heavy contention over the same port or b) a deadlock. I'm leaning towards (a) since we see a comparable amount of mojo::core::ports::MessageQueue::GetNextMessage(). We are going to need help from Mojo experts here - how do we diagnose this problem, and specifically how can we tell which Mojo message(s) we're receiving a lot of? Assigning this to jam@ for said help :)
,
Oct 22
Ken: can you please take a look?
,
Oct 22
I don't know how I can diagnose this further without a repro, unfortunately. The stack clearly indicates to me that this is the browser being hit with tons of IPCs. The fact that there's contention between UI and IO thread on this lock indicates that the offending interface is bound on the UI thread, but that doesn't narrow it down very much.
,
Oct 22
,
Oct 22
Can any instrumentation be added on TOT that would help in debugging this? I'm on dev channel so presumably if we can get something into the next dev build in a week, it might help to debug. Alternatively, if there's something you think I can do with the live instance that's currently hung on my machine that can provide you helpful info, that's another option.
,
Oct 22
If you can attach a debugger to it and see what the UI thread does once it has the lock, we might be able to identify the offending interface.
,
Oct 22
My suspicion is this is related to accumulation of LatencyInfo objects and offscreen OOPIFs constantly submitting CompositorFrames. I can stick a few UMA to track this suspicion.
,
Oct 22
,
Oct 22
"If you can attach a debugger to it and see what the UI thread does once it has the lock, we might be able to identify the offending interface" I don't believe it's possible to attach a debugger to official Mac Chrome builds. Or at least that was the case some time back. Maybe Erik or Elly can correct me if I'm wrong. fsamuel: We could try w/ UMAs, though one issue is that the browser is frozen so I'm not able to bring up e.g. chrome://histograms.
,
Oct 22
Please try to disable site isolation "Site isolation trial opt-out" and report back whether you continue to see the issue. Thanks!
,
Oct 22
Rebooted the hung instance and toggled the flag. We'll see if the issue appears tomorrow (although conditions are not quite the same as having it be up over a weekend.)
,
Oct 22
> I don't believe it's possible to attach a debugger to official Mac Chrome > builds. Or at least that was the case some time back. Maybe Erik or Elly can > correct me if I'm wrong. Would you be able to make a local build and use that as your daily driver? That would let you attach Xcode if the issue occurs again.
,
Oct 23
There was some discussion about whether OOP-D (the VizDisplayCompositor experiment) was enabled. In the sample from #15 it appears to be enabled and in the samples from #30 it appears to be disabled, so the issue is probably not related to OOP-D. A total wild guess but is it possible that the browser IO or UI thread ends up descheduled while on the lock screen (eg. some system API call blocks when on the lock screen or something) but some child process(es) are still running? A large number of IPC messages would get queued up, explaining the memory usage, and the browser would have to be process all of the IPCs before becoming responsive again.
,
Oct 23
As an update, with site isolation disabled, I did not experience the issue this morning. However, I must emphasize that the scenario is different - the issue yesterday was after a weekend of inactivity and my session currently is likely much lighter than it was last week before the weekend (since I only restarted the browser around 5PM yesterday and it did not have time to accumulate as much open windows and tabs as my regular usage is). However, it is a signal, since I didn't even get a short delay this morning at all when unlocking. We can see how things are tomorrow as well, when my browser session hopefully becomes a bit heavier.
,
Oct 25
We had a power interruption on Tuesday night, so no data from yesterday morning since the machine was off. This morning I did not experience this issue. (Again with site isolation off.) So there is some evidence that site isolation causes it or makes it more likely to happen. Still, I didn't yet have 2+ days of being away from the machine like I did on the weekend, so that would provide a stronger signal that it's site isolation related.
,
Oct 26
Issue 890931 has been merged into this issue.
,
Oct 29
FYI: While the issue didn't appear on consecutive weekdays with SiteIsolation disabled, it did appear after the weekend. So SiteIsolation off doesn't fix it.
,
Oct 29
M71 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.
,
Oct 29
M71 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.
,
Nov 1
As an update, I've been running Canary along-side dev (dev being the one that's freezing for me) and have some more observations to report. Whereas dev did not freeze after disabling Site Isolation except after the weekend, Canary (where I didn't disable SiteIsolation) is freezing every day (i.e. each morning it'z frozen). So Site Isolation makes the problem more prevalent it seems. I haven't had cycles to run my own build so it can be debugged. Busy with lots of other fires. :\
,
Nov 1
I'm kicking off a Mac build to see if I can leave it running and repro for debugging. Any particular tabs you consistently have open when this happens?
,
Nov 1
Just typical workflow - gmail, crbugs, docs, critique, cider, b/,
,
Nov 2
Overnight has produced nothing so far, but I'll leave it running over the weekend. A few more questions they might affect repro: any interesting extensions installed except for (I assume) the default corp ones? And do you know if your device actually goes to sleep, or do you keep it awake when idle?
,
Nov 2
I'm not sure which the default corp extensions are, since I installed a ton immediately after getting my computer. An inclusive list of installed extensions: aapocclcgogkmnckokdopfmhonfmgoek : Slides : version 0_10 abjoigjokfeibfhiahiijggogladbmfm : Google Corporate Extension Reporter : version 1_7_6 ahfgeienlihckogmohjhadlkjgocpleb : Web Store : version 0_2 aihpiglmnhnhijdnjghpfnlledckkhja : BeyondCorp : version 4_28 aohghmighlieiainnegkcijnfilokake : Docs : version 0_10 apdfllckaahabafndbhieahigkjlhalf : Google Drive : version 14_3 bfbbnoklfpdkepgoclfceoaebeoeibed : CSAI URL Reporter : version 1_7 bkhfbppagaombgamedpdnepnganpmpbb : #plx Theme Changer : version 0_2_0 blpcfgokakmgnkcojhhkbfbldkacnbeo : YouTube : version 4_2_8 cfmgaohenjcikllcgjpepfadgbflcjof : Google Corp SSH Extension : version 1_12 chphlpgkkbolifaimnlloiipkdnihall : OneTab : version 1_18 cjpalhdlnbpafiamejdnhcphjbkeiagm : uBlock Origin : version 1_17_0 dhgjflpimlbndbpamnkoepaacagejgda : Google Play Music : version 1_396_0 epagckfjcoebkoiepddniokanaanjbog : Eng Level : version 4_4_4 felcaaldnbdncclmgdcncolpebgiejap : Sheets : version 1_2 fhcagphnoanpgcbhcjlijdbeeggldbof : Policy Notifier : version 1_1_3 gbchcmhmhahfdphkhkmpfmihenigjmpp : Chrome Remote Desktop : version 70_0_3538_21 gdfknffdmmjakmlikbpdngpcpbbfhbnp : Tune (beta) : version 0_1_3 gfdkimpbcpahaombhbimeihdjnejgicl : Feedback : version 1_0 ghbmnnjooekpmoecnnnilnnbdlolhkhi : Google Docs Offline : version 1_7 gmbmikajjgmnabiglmofipeabaddhgne : Save to Google Drive : version 2_1_1 hdokiejnpimakedhajhdlcegeplioahd : LastPass: Free Password Manager : version 4_19_0_5 hinmcgipjjndkedddmmpidnjikjebejj : Crease : version 1_1_0 iodihamcpbpeioajjeobimgagajmlibd : Secure Shell Extension : version 0_9 jnjfeinjfmenlddahdjdmgpbokiacbbb : Quick Tabs : version 2017_10_8 klbibkeccnjlkjkiokjodocebajanakg : The Great Suspender : version 7_0_109 kmendfapggjehodndflmmgagdbamhnfd : CryptoTokenExtension : version 0_9_73 kngjcibmkbngcpnaoafbgkicpgmdehje : SecureConnect Reporting (Internal version) : version 1_0_13 lkjlajklkdhaneeelolkfgbpikkgnkpk : gnubbyd corp : version 0_0_11 mbcjcnomlakhkechnbhmfjhnnllpbmlh : Tab Pinner (Keyboard Shortcuts) : version 1_2 mfehgcgbbipciphmccgaenjidiccnmng : Cloud Print : version 0_1 mhjfbmdgcfjbbpaeojofohoefgiehjai : Chrome PDF Viewer : version 1 neajdppkdcdipfabeoofebfddakdcjhd : Google Network Speech : version 1_0 nkeimhogjdpnpccoofpliimaahmaaome : Google Hangouts : version 1_3_10 nmmhkkegccagdldgiimedpiccmgmieda : Chrome Web Store Payments : version 1_0_0_4 noondiphcddnnabmjcihcjfbhfklnnep : Password Alert : version 1_27 oalceifbkhhehhinpifagdnickeeehlk : Recursive Bookmark Sorter : version 0_2_0 onlkggianjhjenigcpigpjehhpplldkc : draw.io Diagrams : version 8_7_0 pjkljhegncpnkpknbcohdijeoejaedia : Gmail : version 8_1 pkedcjkdefgpdelpbcmbmeomcjbeemfm : Chrome Media Router : version 7018_903_0_0
,
Nov 2
Thanks. Nothing in that list seems likely to elicit extraordinary behavior. I'll leave the workstation locked and awake over the weekend.
,
Nov 2
,
Nov 2
If you are able to keep running another build over the weekend, it'd be interesting to try with https://chromium-review.googlesource.com/c/chromium/src/+/1278535 applied. It should help with pages with oopifs (when site-isolation is turned on), if that is the main contributor to the problem.
,
Nov 5
M71 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.
,
Nov 5
Unfortunately I still have no repro. My Mac has been awake and running a build from ToT (with screen locked) since Friday. It's still doing just fine, CPU and memory usage look normal.
,
Nov 5
Curious - are you signed in with multiple accounts? For me, I am signed in with my corp account and my personal account. Sorry to leave that detail out in the original report. Can I provide additional details?
,
Nov 7
I built a local debug Chromium build but it's super slow. So not sure I can use it for daily use. On the other hand, the CL from comment 69 is now on canary (https://storage.googleapis.com/chromium-find-releases-static/b04.html#b04ad36) so I think today I'll just use canary for my day to day and see if the problem still exists tomorrow.
,
Nov 7
Note that that CL was reverted immediately afterward.
,
Nov 8
M71 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.
,
Nov 13
Friendly ping to look into this issue and to provide further update on this issue as it has been marked as a stable blocker. Thanks!
,
Nov 13
The issue is still ongoing for me - only happens on my corp-issused laptop. Haven't tested on other platforms (but I can if that would be useful).
,
Nov 13
Reminder M71 Stable is approaching VERY soon. Please review this bug and assess if this is indeed a RBS. If not, please remove the RBS label. If so, please make sure any planned work will be tested in Beta and verified before the Stable date. Thank you. Requesting to take a look at M71 blockers ASAP due to upcoming Thanksgiving holidays next week.
,
Nov 15
Reminder M71 Stable is approaching VERY soon. Please review this bug and assess if this is indeed a RBS. If not, please remove the RBS label. If so, please make sure any planned work will be tested in Beta and verified before the Stable date. Thank you. Requesting to take a look at M71 blockers ASAP due to upcoming Thanksgiving holidays next week.
,
Nov 15
As this is regressed in M70 and we're very close to M71 stable promotion, pls target fix for M72.
,
Nov 27
Gentle ping for any update on this issue marked as blocker. asvitkine@: Is this working fine on the latest M-72 post C#73.
,
Dec 3
Friendly ping to get an update on this as per C#81 & it is marked as RBS.
,
Dec 3
The issue is unfortunately still not resolved.
,
Dec 3
We can't RBS this - we've already shipped it in multiple stables :( |
||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||||
Comment 1 by asvitk...@chromium.org
, Sep 17