Closed ChaosCom closed 5 years ago
created a profile that doesn't contain uBlock Origin
If you install uBO in that new profile, do you still have the problem?
Also, please provide Google Chrome version as requested.
I tried with a new Profile, no such issue. google.com opens as expected.
Lack of STR and chrome version will not help the issue you face.
I am pretty sure that kind of symptoms has been reported in the past when uBO updates. Usually forcing a restart of the browser worked. To be sure, disable the setting "Continue running background apps when Chromium is closed" should be un-checked ("Settings" => "Advanced" => scroll to the bottom).
Example: https://github.com/gorhill/uBlock/issues/1858#issuecomment-331643175.
There's always some issue whenever a stable release is updated, just can't catch a break with that.
I'm using Chrome 53 (really outdated, I know, I have my reasons), and I'm having this issue since late last night, well after uBlock updated, it was working until then. Downgrading to 1.18.6 and even manually installing 1.18.8 worked, but I lost my settings since I did a manual install and can't backup my regular 1.18.8 settings,
I want to assume it's a filter/setting that's causing issues, especially since manually installing 1.18.8 and not having my regular settings works, but since I can't access my regular settings due to the hang, I can't fix it.
I'm back from some tinkering. I installed the older version uBlock0_1.18.6.chromium in developer mode, and the extension was running fine at first ... that is, until I
Updating the filter list alone wasn't enough to make the older version loop, but after a restart the older version was hanging just like the 1.18.8 one - which makes me now suspect it's a filter rule. I had to manually trash the unpacked dev extension to make a screenshot of the lists that were updated: https://i.imgur.com/7wXNYI8.jpg
@gorhill and @uBlock-user: Is there a way of making ubO scan and report "fishy" rules from one of those lists ?
I want to assume it's a filter/setting that's causing issues
Not possible really. Well, I will walk back on this, I do recall a case of awfully-crafted filter which caused a very bad regex internally -- it had a lot of wildcards in it.
The only hypothesis I can think of which could create an infinite loop in the code is that uBO's on-disk storage selfie got corrupted.
@gorhill
"Continue running background apps when Chromium is closed" was always disabled for me. My Chrome version is v56.0.2924.87
a screenshot of the lists that were updated
These are default filter lists, so I forced a hard cache purging (ctrl-shift-click purge caches button), restarted, forced an updated, restarted. At no point did I experience an infinite loop.
Since both of you are using relatively old versions of Chrome, this might be an issue specific to these. Are there portable versions of Chromium out there for Linux -- and especially from reliable source (I won't download/install from random sites).
Also, are these 32-bit versions of Chrome/ium?
I think you could try https://www.slimjet.com/chrome/google-chrome-old-version.php
@gorhill
Yea, mine is Google Chrome 56.0.2924.87 (Official Build) (32-bit) Revision 0e9a9a6f3676ae439b78cd9b3f62b4193c3ac7d5-refs/branch-heads/2924@{#895}
So you are using a 32-bit browser in a 64-bit OS... I wonder if this could be the issue. uBO uses typed arrays. Though this was also the case in previous versions, a new portion of code was converted to typed array in 1.18.8. Would it be difficult for you to use a 64-bit version of Chrome to see if this makes a difference?
But how does that explanation fit into the test I described earlier with uBlock0_1.18.6.chromium ? Or were you meaning to say that the additional portion was introduced with 1.18.x ? I'm still kinda leaning towards @Latias4Ever 's suspicion...
I'm still kinda leaning towards @Latias4Ever 's suspicion...
Well one way to find out would be to enable one filter list at a time and see if the issue manifest when updating it.
I would love to try that, but the problem is the dashboard doesn't open up at all since the extension is constantly hanging.
Ok, to recapitulate, @ChaosCom said here an hour ago that he could reproduce:
Updated the filter lists AND Restarted the browser
When the filter lists are updated, all the lists are parsed, compiled and the compiled lists are all reloaded, while at launch time the compiled filters are all loaded. If this was a filter causing the issue, it should happens just after updating all the lists, and we should be able to reproduce on our side.
What could help is to try to reproduce in a new profile, and select only one filter list at a time, and even with no list at all at first. This is time-consuming but given I can't reproduce on my side, I don't see any other way for moving forward.
Google Chrome 56.0.2924.87
So to reproduce one will need that version ?
@Latias4Ever @gorhill The problem with trying to reproduce a FILTER issue (if it really is a filter after all) is the potentially ever-changing environment of filter definition updates.
I have since my last message again thrashed and re-installed the older version uBlock0_1.18.6.chromium in developer mode, and tried to put gorhill's suggested method to the test of manually enabling and updating each single default filter list there was, interspersed with restarting the browser to see if it hangs. To my surprise, I am now left with a working version of 1.18.6 where all the default lists are updated correctly and the extension doesn't hang nor interfere at startup.
However! I am in the comfortable position of still having the untouched hanging 1.18.8 version on my system, so I went ahead and diffed the filter definition updates in the "assets" folders, and - perhaps unsurprisingly- the filter definitions are not 100% the same. In particular, the following 2 files changed in the last couple hours
Does anything of this look peculiar @gorhill ?
@Latias4Ever
Also, given that uBO stores filter definitions in the "assets" subfolder of your extension under
C:\Users\
@gorhill I updated to the dev branch and the issue is gone.
it seems that the extension is looping on a single core without doing anything (checked via task manager).
Do you mean by this that the CPU usage shows as 100% for uBO?
@gorhill Well technically, it was showing as 12.5% because 4 cores * 2 (Hyperthreading) for me, so anything blocking a single core will show as 1/8 th = 12.5%... But yea, i verified via Chrome Task Manager that the Task "Extension: uBlock Origin" was eating all the cycles..
If you open the dev tools for uBO (I am assuming you know how), then select the "Source" pane in dev tools, then force a restart of uBO, then create the condition of hung uBO, does pausing in the debugger succeed? I remember facing such situation during development and having the dev tools opened before the infinite loop allowed me to pause successfully.
I updated to the dev branch and the issue is gone.
Nothing of significance changed in the dev build, at least nothing I can link to an infinite loop -- well except for uBO's filter lists in the package.
I've attempted to do as @ChaosCom suggested and moved the two mentioned files, but uBlock is still hanging. In fact, I disabled the manual installation of uBlock, and then re-enabled it, and it also started to hang, it only started working again after reinstalling it. This was the same manual installation from earlier today.
I've updated the filters after reinstalling, and it's still working for now.
You can not modify files in the package, this will cause the browser to see uBO as a tainted package. All the data is stored through extension API chrome.storage.local
, you are not going to find this inside uBO package -- uBO has no access to the file system.
In that case, I'm not sure what I can do. I've attempted to open the Dev Tools for the hanging uBO, but the window doesn't even open, the extension is fully frozen.
@Latias4Ever Just to be sure I understand: you do not get the hang with 1.18.9b0, you do get the hang with 1.18.8 -- using the same uBO installation, i.e. using the same settings/lists? I am getting confused with all the various information.
I'll go and describe all the steps I've taken:
My 1.18.8 from the Web Store, the one I've had since first installing, is hanging since late last night.
The manual 1.18.8 installation was done earlier today, about 4 hours ago, it started to hang after I disabled it to attempt @ChaosCom's suggestion (and re-enabling the Web Store installation) and re-enabled it. I reinstalled this again, and it's working right now.
I haven't installed 1.18.9b0 at all yet.
it started to hang after I disabled it to attempt @ChaosCom's suggestion (and re-enabling the Web Store installation)
How do you know the manual installation hung if you also enabled the Chrome Web Store installation (the one with the problem) at the same time?
I disabled the Web Store installation, and then disabled and re-enabled the manual installation.
Updating it to say it happened again after a test. I disabled the manual installation, re-enabled the Web Store installation, then disabled the Web Store installation, and re-enabled the manual installation. The manual installation started to hang, Web Store is still hanging. I'm installing 1.18.9b0 now to see if the issue remains on this version. Note that I didn't do anything since my last post, so this was only several hours after I manually installed.
Upgraded to google-chrome-stable-59.0.3071.86-1.x86_64 on Fedora 29 yesterday and I am experiencing the same issue. Removed uBlock for now, this heled.
@gorhill Another update, the manual installation has started to hang on its own after starting up Chrome today. This was with 1.18.9b0. I believe this was caused by the fact Chrome disabled the extension for being a manual installation, until I told it I didn't want to uninstall it.
Could you try 1.18.4 instead of 1.18.6? I am wondering if this could be related to the new Public Suffix List code in 1.18.6.
*18
I am going to run an old version of Ubuntu from a USB stick to investigate with an old version of Chromium.
Chrome v51 user here. Having the same issue. Thank you for your efforts @gorhill
Keeping this open so users need not to open new issues in the tracker.
I installed 1.18.6 earlier after I made my last post. I just experimented by disabling and re-enabling it, it started to hang again. I've done as suggested and installed 1.18.4 now. Since this happens only when I try it a few hours after reinstalling, I'll only be able to give an update later.
As said above, 1.18.6 is essentially the same as 1.18.8, hence why I suggested you use 1.18.4.
By the way, so far I have narrowed the issue to selfie loading. A selfie is generated ~7 minutes after lists are updated. So reloading uBO after a selfie is created causes the issue.
A few hours have passed, and I've done the experiment once again, I've disabled and re-enabled 1.18.4, and even reloaded it, it hasn't frozen at all. I believe it might be selfie loading, I'll attempt this again at another time to verify if it's still working.
This is what is causing the issue: https://bugs.chromium.org/p/chromium/issues/detail?id=268991.
Now I have to find out in which version this was fixed, the bug entry does not tell.
Edit: This was fixed in Chromium 60.
Would you be bumping min. version to 60 ?
It's tempting given that from this issue we can tell nobody using an older version of Chromium is using the dev build of uBO -- the issue here would have been caught before stable release if this was the case.
Now it's closed or? I don't update my Chrome version from v52 because of the Direct Write issue. Does this mean, I have to stick to 1.18.4 - which is still working?
@shaft17 it's closed because it was fixed in a commit
Sent from my moto g(6) using FastHub
I have the same on my raspberry pi (fully apt-get update & upgraded). Its chromium is: Version 56.0.2924.84 Built on Ubuntu 14.04, running on Raspbian 8.0
I rebooted the thing to be sure to kill chromium, and I let the webpage load for several minutes, and it worked after a while, so it might be the selfie thing.
Just joining the conversation to show why some people are on old versions of chrome/chromium :-)
Prerequisites
Description
With the auto-update to uBlock Origin 1.18.8, I suddenly get the dreaded "Waiting for extension uBlock Origin..." message that some people already reported on rare occasions, where it seems that the extension is looping on a single core without doing anything (checked via task manager).
My "start page" (the default page in chrome that you see that contains a google search box and 8 of your most used urls) initially loads, but any search request or navigation to any site doesn't complete.
Opening a new tab results in a white page (not even the default page loads) with the only message in the status bar saying "Waiting for extension uBlock Origin...".
I can definitely confirm it's an ublock origin issue just by having created a profile that doesn't contain uBlock Origin, and can also "re-animate" my old profile by disabling the extension. Also, while the aforementioned message in the status bar is showing, I am not able to debug the extension nor force a halt in the debugger.
Is there a way to downgrade uB Origin to an older version, or even give some insight into this somewhat elusive issue (as it keeps re-surfacing for users every now and then) by forcing debugging?
A specific URL where the issue occurs
www.google.com
Steps to Reproduce
Expected behavior:
[What you expected to happen]
Actual behavior:
[What actually happened]
Your environment