Unsolved Recurring freeze on startup

szczurnik

@DoctorG ? Flag Cookies is already disabled, I still need it, but once few days, not the whole time, so disabling it was an easy workaround. Now I want to get rid of Background Page: Vivaldi!

DoctorG

@szczurnik said in Recurring freeze on startup:

Now I want to get rid of Background Page: Vivaldi!

Needed, that is the browser.

szczurnik

Why is the process running with the --extension-process flag then and causing so much trouble?

Is there something I can do to debug and report this? Process Monitor fails, as it doesn't capture pipe transfers, and there is no file activity that would indicate what exactly Background Page and Browser are chatting about. Process Explorer just shows the flags and CPU or I/O load and it's done.

DoctorG

@szczurnik Let me check with Process Monitor.
I see in procmon for Network only a few DNS requests.

Pathduck

Vivaldi's "App" process is running with that flag because Vivaldi is an extension - it's a web app running on top of Chromium - makes sense?

You can get more info in ProcExp going into the process properties, and going to the different tabs.

as it doesn't capture pipe transfers

Why do you think this is "pipe transfers"?

DoctorG

@szczurnik Vivaldi main process has some of its own important subprocesses as a extension
Open vivaldi:system and check Extensions.

szczurnik

@Pathduck because the activity is recorded as I/O, yet there is nothing in disk, nothing in network, so needs to be a different type of I/O. Moreover, I/O of writing process corresponds in volume to the one reading, which usually means there is a pipe between them doing the "balancing". It looks like Browser tries to process some data in loop, but instead of keeping its own in-memory cache, requests it over and over from Background Page.

How much that could be? Freeze can last for 35 minutes at 27MB/s I/O rate, which means over 50GB transferred over pipe with full CPU load processing whatever this is.

Pathduck

@szczurnik True, Chromium browsers use a lot of inter-process communication.

My guess if you can't tell from the task manager (Shift+ESC) which process it is, then it's possibly Mail or RSS feeds, as they are known to cause CPU problems.

Might be trying to download a bajillion mails for local cache from an IMAP server. In that case you would of course also see network IO from the browser's Network Service process.

I can't help much with that though, as I don't use the Mail/RSS client and my very minor testing has not shown such problems.

szczurnik

@Pathduck Mail disabled, Calendar disabled, Feeds disabled since forever. I don't know the trigger, usually happens once few weeks (the only smaller gap was yesterday with two freezes in a single day), so might be a browser update.

I can try with logging, is --enable-logging --v=1 from https://support.google.com/chrome/a/answer/6271282 the good set of flags and with good-enough verbosity? Will it include Vivaldi-specific chatter as well?

Pathduck

@szczurnik Yes, you could try logging, from my notes what I have for most verbose logs:

vivaldi --enable-logging=stderr --v=3 > log.txt 2>&1

https://www.chromium.org/for-testers/enable-logging/

You could possibly do a capture with Process Monitor too, but if it's IPC I don't think it captures that.

Also things to think about:

Do you have an insane amountof open tabs?
Have you set session tabs to lazy load?
Do you have an insane amount (i.e. 10k+) of bookmarks?
Do you have a insane amount of history (i.e. stored "for ever")?
Do you have a lot of other data types?
Have you enabled Sync?
What does chrome://sync-internals say about data?

szczurnik

@Pathduck Logging flags added (is --v=3 the better value?), replying to the following:

11 tabs in three worspaces total, current worspace has 1.
should be lazy - confirmed, Always Load Pinned Tabs is set as well, and while I don't have any in the current workspace, some might still be in another ; loading disabled for Pinned Tabs now.
bookmarks seem to be between 100 and 150, many of them default.
history is my thing, guilty of a 212MB file (though I don't recall disk I/O on its file during freeze, it could be that Browser is locked down before it can reach the history loader).
dunno.
no Sync, no account.
nothing seems to be in chrome://sync-internals (though I'm running an instance from a "quick start", as the current run has not been affected by freeze), not sure how I'm supposed to work with this tab.

Current flags: vivaldi.exe --disable-features=UseEcoQoSForBackgroundProcess --log-file=D:\Vivaldi.log --enable-logging --v=3

Pathduck

@szczurnik said in Recurring freeze on startup:

history is my thing, guilty of a 212MB file (though I don't recall disk I/O on its file during freeze, it could be that Browser is locked down before it can reach the history loader).

That might be it then.
I store only 1 month, 20MB.
There's good performance reasons why no other browser allows storing endless history.

If the theory is that the problem is caused by History, move the History file out somewhere and test again.

Current flags: vivaldi.exe --disable-features=UseEcoQoSForBackgroundProcess --log-file=D:\Vivaldi.log --enable-logging --v=3

Don't change the shortcut properties.

Close the browser
Open a command prompt
Navigate to the program Application folder
Run the command vivaldi --enable-logging=stderr --v=3 > log.txt 2>&1
Reproduce the problem
Close the browser
Examine log.txt

If you mess with I wrote I can't answer you if things don't log as you expect. I don't know how logging works, this is only what I've copied and know works.

szczurnik

@Pathduck a reminder: reproduction will take weeks, so flags have to stay permanently regardless of their performance effect, also I can't modify any of the crucial components like extensions or history UNLESS a deterministic scenario will be found - I would otherwise lose a large part of browser possibly for months without any guarantee.

I close and start browser several times each day, so I might have a hundred unaffected runs before the next one - and no idea when this will happen! I hope it won't be a thriller-type scenario, when I will have to access something immediately to stop bad things from happening - only to have browser freeze and cause a tragedy.

Pathduck

@szczurnik OK but I don't know if that log statement you have there works. You'll just have to test if the log you get gives you an idea what might be wrong.

EDIT: Here's why adding it to the shortcut target won't work:

> vivaldi --log-file=G:\download\Vivaldi.log --enable-logging --v=3

d:\bin\Vivaldi-stable\Application
> [7480:11208:1018/150919.404:ERROR:vivaldi_data_url_utils.cc(174)] File not found - G:\download\03609_onicelandsringroad_1920x1080-02.jpg
[7480:3000:1018/150919.404:ERROR:CONSOLE(1)] "Error loading background image chrome://vivaldi-data/local-image/MGKN2ZNV6LJAFMD55DNLPF3AYWSWIBW7.jpg", source: chrome-extension://mpognobbkildjkofajifpdfhcoklimli/bundle.js (1)
[7480:3000:1018/150919.616:ERROR:CONSOLE(242)] "<webview>: Script cannot be injected into content until the page has loaded.", source: extensions::webView (242)
[7480:3000:1018/150923.536:ERROR:CONSOLE(0)] "Unchecked runtime.lastError: The tab was closed.", source: chrome-extension://mpognobbkildjkofajifpdfhcoklimli/window.html (0)
[7480:3000:1018/150923.536:ERROR:CONSOLE(0)] "Unchecked runtime.lastError: The tab was closed.", source: chrome-extension://mpognobbkildjkofajifpdfhcoklimli/window.html (0)
[7480:3000:1018/150925.927:ERROR:CONSOLE(242)] "<webview>: Script cannot be injected into content until the page has loaded.", source: extensions::webView (242)
[7480:3000:1018/150926.253:ERROR:CONSOLE(242)] "<webview>: Script cannot be injected into content until the page has loaded.", source: extensions::webView (242)

It logs a bunch of stuff to console (stderr I think?), you won't get these errors in your log file when launched from a shortcut. The 2>&1 redirects stderr to stdout which is written to log.txt. I actually don't know what the --enable-logging=stderr does, but that's what the docs says to use.

And shortcuts in Windows can't redirect output to files.

I guess if this is not easy to reproduce in a single launch, you could write a short batch file that does the same and is launched from the shortcut instead.

szczurnik

@Pathduck

[18024:14928:1018/152112.571:ERROR:CONSOLE(242)] "<webview>: Script cannot be injected into content until the page has loaded.", source: extensions::webView (242)

I hope this line is a sign that even errors are captured in this log. An unexpected side effect is a console window permanently running with a Vivaldi name on it. At least performance does not hurt as far as first few minutes go.

Pathduck

@szczurnik There will be a LOT of logging, most of it completely irrelevant to the problem, even ERRORs and WARNINGs.

This kind of looking at logs is really only meant for Chromium developers. And I'm not one.

That's why I doubt the logs will do any good. There's no guarantee what you're looking for will even be logged.

That's why I recommend a method of trying to exclude different variables by removing potential causes, starting in a clean profile and trying to reproduce etc. This does not require one to be a Chromium developer to read the logs.

Just basic science - make a theory what the cause might be, then test that theory.

szczurnik

How can I confirm that the theory is valid?

Pathduck

@szczurnik said in Recurring freeze on startup:

How can I confirm that the theory is valid?

You will have evidence for the theory when you can reproduce the problem in a clean profile using the steps you've tried.

To even get a theory, a good test would be:

Move the History file out of the browser profile, starting from a clean slate.
If the problem is gone - that's a good indication that's where the problem lies.
Now you have a theory - "The History file is the problem"

Then to gather evidence for this hypothesis:

Copy the History file into a new clean profile (installed as Standalone for instance)
See if the problem appears - now you have some evidence for the theory.

Not saying History is where the problem lies, it's just a theory based on a single point of data - your humongous History file. Actually, to be strict, this is not a theory, it's a hypothesis...

szczurnik

The problem is, there are no hints linking history to the freeze, so if I had to disable* history for two months just to check with reasonable probability if it is the trigger, I would lose quite a lot of browser features I need - and the only way to shorten this would be getting a freeze even with history disabled, as this would reject the hypothesis. I think this cost outweighs the problem.

*considering the extent of time necessary for confirmation, keeping history enabled would create buildup big enough to trigger the freeze and give a false negative.

szczurnik

I have captured the logs - manual review shows nothing for the entire half hour of the freeze, all that intense activity was not worth even a mention, why TF are there any logs called "verbose", if they aren't doing their job? If not for renderer reacting to Vivaldi window accidentally brought to forefront, it would have been 30 minutes of complete silence. I tried guessing something from logs preceding and following the gap, yet nothing seems to stand out to me; maybe comparison with a normal run would expose an abnormality... Very little is logged anyway, 99% of file volume is renderer with diarrhea.

*table flip*