100% CPU utilization

[dmgerman]

Please read the CONTRIBUTING guide before submitting an issue.

Description

when visiting some sites, ghostery uses 100% CPU

chrome will report that ghostery has been killed. the web page being visited remains as-is.

Expected Behavior

use CPU for some time, then stop using it.

Actual Behavior

uses 100% CPU

Steps to Reproduce

using chrome visit:

http://fivethirtyeight.com

wait for few seconds. the cpu will go up.
look up the PID of the process using most of this CPU (e.g. use top)
Kill the pid that is using the CPU

Versions

8.1.0, using Chrome under Linux.

[christophertino]

I can reproduce this. Completely locks up Chrome when loading http://fivethirtyeight.com/.

[christophertino]

@dmgerman It looks like there's a Nielsen tracker on that page that goes into an infinite loop when blocked. If you unblock 'NetRatings SiteCensus' in Ghostery, does Chrome perform normally?

We've had issues with other trackers from Nielsen causing similar lockups.

[dmgerman]

Yes, disabling "Netratings SiteCensus" solves the issue.

…

On Tue, Mar 27, 2018 at 11:50 AM, Christopher Tino ***@***.*** > wrote: @dmgerman <https://github.com/dmgerman> It looks like there's a Nielsen tracker on that page that goes into an infinite loop when blocked. If you unblock 'NetRatings SiteCensus' in Ghostery, does Chrome perform normally? We've had issues with other trackers from Nielsen causing similar lockups. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKM8Lm_4SBtdtA2LXL94fNuFj6Fgg81ks5tion-gaJpZM4S6XPK> .

-- --dmg

--- Daniel M. German http://turingmachine.org

[christophertino]

Ok thanks. We are working on a surrogate solution for this tracker.

[zarembsky]

The fix will be in the next (8.1.1) release.

[jimon]

I have similar issue with 100% CPU utilization, but it is even more strange - it reproduces even if I just open chrome and look at the start page (aka no pages open).

Ghostery 8.1.2
Chrome Version 67.0.3396.62 (Official Build) (64-bit)
MacOS 10.13.4

Is there a way for me to get more details about where it hangs?

[slarty667]

I have the same issue as @jimon - simply opening the browser and looking at the empty start page will already shoot up the processor usage to 100%. The Chrome Taskmanager says that it's only this plugin using so much CPU.

Ghostery 8.1.2
Chrome Version 67.0.3396.62 (Official Build) (64-Bit)
MacOS 10.13.4

[tliet]

Same here, Ghostery 8.1.2 shoots up to 100%-130% CPU utilisation (via the Google Chrome Helper) with an empty browser. So, this is probably an issue in this version.

[talksinmath]

Same problem here, Ghostery 8.1.2 and Chrome 67

[christophertino]

I see it too. Looks like something changed in Chrome 67. We'll dig into this today.

@jimon You can debug Ghostery at chrome://extensions/ and click the "background page" link under Ghostery.

[wilk-polarny]

Here too with Chrome stable 67.0.3396.62 on macOS. Are you guys mining some crypto currencies, or what?

Anyways, got thousands of the following messages on the console:
background.js:formatted:4043 Uncaught (in promise) u: module 'adblocker' is disabled at Object.isReady (chrome-extension://mlomiejdfkolichcflejclcbmpeaniij/dist/background.js:8:22748) at Object.action (chrome-extension://mlomiejdfkolichcflejclcbmpeaniij/dist/background.js:8:22991) at Object.handleRequest (chrome-extension://mlomiejdfkolichcflejclcbmpeaniij/dist/background.js:8:716006) at Object.dispatchMessage (chrome-extension://mlomiejdfkolichcflejclcbmpeaniij/dist/background.js:8:715861) at o.chrome.runtime.onMessage.addListener (chrome-extension://mlomiejdfkolichcflejclcbmpeaniij/dist/background.js:8:1517791) at EventImpl.dispatchToListener (extensions::event_bindings:403:22) at Event.publicClassPrototype.(anonymous function) [as dispatchToListener] (extensions::utils:138:26) at EventImpl.dispatch_ (extensions::event_bindings:387:35) at EventImpl.dispatch (extensions::event_bindings:409:17) at Event.publicClassPrototype.(anonymous function) [as dispatch] (extensions::utils:138:26)

[jimon]

Weirdly it seems to be fine on Windows with Chrome Version 67.0.3396.62 (Official Build) (64-bit) and 8.1.2 Ghostery.

[christophertino]

Yea we're not seeing it on Linux either. It seems to be specific to macOS. We're still trying to find the source.

[pinalbhatt]

same here on mac.

[sjferwerda]

Also on Mac for the last two days. Chrome 67+ beta. Ghostery 8.1.2. MAC OS 10.13.4

[mick-t]

Seeing it on my OSX system. Let me know if there's anything you'd like me to test.

[dmzimmerman]

I have also been seeing this on macOS for the last few days.

[dcharkes]

Same here:

• Ghostery 8.1.2
• Chrome: Version 67.0.3396.62 (Official Build) (64-bit)
• MacOS: 10.13.4

[isdn]

It seems that the issue might be related to some changes in Chrome v.67 on MacOS.
We have faced it with some our local sites even without ghostery.

[christophertino]

I see a Chromium bug here

[seansfkelley]

Same here. I disabled (though did not uninstall) all non-Ghostery extensions, then quit and reopened Chrome and confirmed that, even with no tabs open, Ghostery pegs the CPU to 100%.

• macOS 10.13.3
• Chrome 67.0.3396.62 (stable channel, I believe)
• Ghostery 8.1.2

My settings are defaults, except that I (1) turned on blocking for everything with
"Block All" and (2) disabled the purple box.

[dinvlad]

Same here, Chrome 67.0.3396.62, MacOS 10.12.6, Ghostery 8.1.2

[christophertino]

We have a test build going through regression now. It should be out to the Chrome store this afternoon.

[ghostwords]

@christophertino Where can I find the code fix for this issue?

[jsignanini]

@ghostwords for us it was coming from the cliqz browser-core dependency. Unfortunately the German developers are out on national holiday today so we were forced to manually change the node dependency and make a new build with it. So you won’t see the change in the source until they push it to the code on their end and we update said dependency.

And the issue was a synchronous XMLHttpRequest call. For some reason Chrome 67 in OS X loops infinitely when you make a call like that.
See https://bugs.chromium.org/p/chromium/issues/detail?id=848210

[Jstuddard]

Yup, got it to. MacAir fan has been running for a week and finally decided to look into it and it is Ghostery Extension. Looking forward to the fix. Love your program!

[rusmaxham]

Until Chrome releases a fix for the synch XMLHttpRequest issue in 67, you can work around it temporarily by downgrading to Chrome 66.

[alfiepoleon]

@christophertino Can't wait for the fix, made chrome pretty much unusable for the past 3 days or so.
Chrome Version: 67.0.3396.62 (Official Build) beta (64-bit)
macOS Version: 10.13.4 (17E202)
Ghostery version: 8.1.2

[jsignanini]

Ghostery for Chrome has been updated to 8.1.3. This hotfix release should fix this extreme CPU utilization issue.

[odrotbohm]

Just updated, CPU utilization is back to normal. Thanks for the fast turnaround time, folks! You rock! 👍

[Aziz-Ghostery]

V 8.1.3 is up on Chrome WebStore, please download and confirm the issue is resolved.

[sjferwerda]

Appears to be working, thanks!

…

On Fri, Jun 1, 2018 at 7:15 AM Aziz-Ghostery ***@***.***> wrote: V 8.1.3 is up on Chrome WebStore, please download and confirm the issue is resolved. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABLA5Si_9wN8PbVtIIxvy5b7nyujuHeEks5t4Ux5gaJpZM4S6XPK> .

[seansfkelley]

Resolved for me as well, thanks all!

[Swivelgames]

My MacBook Pro turned into an F/A-18E/F Super Hornet this evening. To my surprise, Activity Monitor showed Ghostery utilizing 280% of my CPU. I was running version 8.0.0.31beta, which was a bit odd.

After checking the Chrome Web Store, I noticed that the version of Ghostery that I had installed was not actually the same as the version in the Chrome Web Store. I've removed it and reinstalled Ghostery from the Chrome Web Store, but I thought this particular issue was a bit odd. Is there an alternative Beta channel that might have been live at one point but is no longer active maybe?

[jsignanini]

Hi @Swivelgames. If you had a beta version in Chrome, then you must have joined our "Ghostery Beta for Chrome" Google Group at some point in time, otherwise you would have not been able to install that beta "channel" version of Ghostery. Removing and reinstalling from the production store listing as you mentioned should be all that you have to do.

Thanks for using Ghostery!

[rusmaxham]

Chrome 67.0.3396.79 with the bugfix is now available: https://chromereleases.googleblog.com/2018/06/stable-channel-update-for-desktop.html

[katastic]

I'm still getting this issue in 2020. I'm uninstalling. Sorry.

[ltalirz]

Not only 100% CPU usage, but also 2.3GB of memory in my case (according to Chrome task manager).
On Chrome 84.0.4147.125, MacOS 10.15.6, Ghostery 8.5.2