Unsolved Recurring freeze on startup

mib2berlin

@szczurnik
Vivaldi is not Chromium, I just want to mention an extension work in Chrome, Brave or Chromium can cause issues in Vivaldi.
So check if this is the culprit with editing your desktop shortcut and add --disable-extensions, then you will know.
This keep extensions from loading.

szczurnik

OK, done.

Disabling extensions: nothing changes.

Disabling favicons: nothing changes.

Disabling history: nothing happens at startup. That is, browser is immediately available. Reinstating history "locks" down the browser again.

In brief summary then:

main process sends something critical (has to be done before browser is made available to user) and based on history to renderer
for larger history file like 200MB this means piping 50GB of data, that requires ~40 minutes of CPU time to be generated at 100% of a single core
this is NOT a Vivaldi-specific behavior, but comes from the parent codebase
this is likely NOT caused by errors in history file, as reproduction at some point was possible for 100% of locally used Chromium-based browsers (big words, but yes, TWO browsers tripping over the same thing at the same time make it improbable to be a data problem＊)
Opera likely managed to isolate and fix/improve the said behavior in their copy of the parent code somewhere between 2024 and 2025
from the above, a code change able to maintain functionality and resolve the problem at the same time should be viable

＊ There is still a possibility of failing SSD leaving garbage in these files, but with 11 months since my initial report the drive would have died several times already, not to mention Opera would continue to exhibit the problem using their own corrupted data, so please let me discard this possibility entirely.

I'm done with analysis and it's at least clear to me, that I have to accept the long startup of Vivaldi, as I consider history critical for use of the browser, so not only discarding the current history would make me blind and very restricted, but also the problem would resurrect itself over time with history file growing back to the original size. The only action that I can and need to take is to move away any services I use that must be available immediately, not after 40 minutes of waiting.

That's it, cheers.

mib2berlin

@szczurnik
Hi, some users here in the thread have up to 1 GB history files and Vivaldi starts fast.
Disabling extensions is not the same as keep them from loading, did you test --disable-extensions?
My SSD can read 500 MB/s, it cant be take 40 minutes to read a 200 MB file.
I still think your file is corrupted, as I mentioned, create a new profile in Opera, delete the history files and copy your files over, then you know if it is the browser or your history.
No idea why the second Chromium browser does the same, same history file size, same extensions in use?

szczurnik

@mib2berlin

Yes, this was done with --disable-extensions, in fact the current run is still with extensions disabled.
Reading history file from SSD is so immediate I was almost not able to capture this I/O activity when debugging; the problem is caused by pipe between processes, which is done entirely in RAM and is not a simple "file transfer", but something heavily computational - let me say this again, 40 minutes of CPU time, a x264 4K encode of a minute-long video needs less even without GPU!
Opera is actually OK now, its history is about half of the size of Vivaldi's history, had the problem but then stopped without any changes on my side.
Extensions were already excluded, this is internal to the browser itself. I don't remember any flags/settings that would have such an effect.

mib2berlin

@szczurnik
The history file is a database file, you cant compare this with encoding a video.
Anyway, I am out of ideas now why Vivaldi need 40 minutes to start for you.
We had a big history test file anywhere but i can't find it.

EDIT: I added a comment in your report about you starting without extensions.

mib2berlin

@szczurnik
Oh, I see your/this report VB-110453 was closed as "Can't reproduce".

shaneb

@szczurnik so I have been complaining about this EXACT issue elsewhere in the forums, and I have added data for this discussion. I have the issue where Vivaldi, on startup, will act as though it's loading the tabs from my previous session for MAYBE 3 seconds at most, then FREEZE UP. This freeze lasts for anywhere between 7 minutes on the low end to maybe 20 minutes for me, witch the average being about 12-15 minutes lately. Once it's loaded Vivaldi seems to be working fine more or less.

I went through many of these same steps, i think mib2berlin helped in my thread as well. I have been testing the Extensions as they kept asking you to do, however I have 29 (active) extensions running, so this has taken some time. I have gone through just about all of them aside from 1 or 2, and run into the freeze no matter if the extensions are disabled or not, but I will do a full --disable-extensions test run soon just exclude the possibility, as szczurnik has.

With the most recent test I did see something however, which supports this person's findings. One or two Vivaldi.exe processes were going CRAZY with I/O read/writes. So much so that I (before even ever finding this thread and info) loaded up Process Explorer to dig into wtf was going on. It was reporting like 100GB of data transfer, which is insane considering I only have like 160GB of free space and definitely would have noticed if that were actually file system read/writes happening. What I saw was that the I/O was not happening on the "Read" or "Write" side of the I/O but rather the "Other" section of the I/O, which I presume is what op was talking about when they mentioned piped I/O activity. Also for what it's worth, I don't recall there being ANY real network activity at the time of all the crazy I/O during this startup freeze, which made me want to check my user data files to see if anything looked strange, but best as I can tell there were no log/config/any other files that seem to be having any noticeable issues with spinning out of control.

I also noted the parameters of the Vivaldi process that I was looking into, and compared it against the one @szczurnik listed here. There were only 2 correlations I noticed:

My --field-trial-handle=7000,i,8519245798395156052,6423931506109139951,262144 parameter also ended in 262144. I learned this is just "The size of the shared memory segment" for the field trial, nothing really.
I also go out of my way to manually add the parameter --disable-features=UseEcoQoSForBackgroundProcess into my startup shortcut. This was in effort to disable Windows' Efficiency Mode from tanking performance, and it never really worked well anyways, I found a better solution, so I will test removing this to see if it helps my issue.

I also run into this issue on startup, every time, so reproducing for tests is easy, although sitting for 10-20 minutes waiting is the pain. Regarding the other thoughts brought up in this thread... I am not as tied to my history information as op, so even though I would prefer not to, I can test clearing my history; although I only keep 3 months of history, which really should not be a problem. I do have TONS of bookmarks, I make use of the Bookmark All Tabs feature regularly to close out sessions and free up memory. But even still I do not think my total bookmark count rivals the numbers listed by the moderator here earlier.

My primary guess has been that I expected this was tied to the loading of previous tab session data, as I expect there is a lot of information in there that needed to be loaded. I will say that I also noted that my heaviest Vivaldi process now seems to be the "Background Page: Vivaldi" process, which I just assumed (or maybe looked up in the past) was the process that managed background hibernated and lazy-loaded tabs. The tabs that have been unloaded from memory for the most part, just keeping the barebones perhaps, but as they pile up perhaps this causes an issue? Or perhaps there is an issue with background tabs being unable to get some vivaldi code injected since it needs to occur after page load, but they're not meant to ever load. Just theorizing. I also wonder if a process using localhost network connections to send/receive data to itself for inter-app communications would show under "Network Activity" since it technically never hits the network or uses up bandwidth. I am not sure how Vivaldi and Chromium parts actually all communicate.

I actually downloaded ProcMon, and some of the other NirSoft/SysInternals monitoring tools earlier today, but after reading op's experience attempting to monitor the interactions I am not expecting to see much. I will move forward with those tests when I get a free moment and report back here if I find anything further.

szczurnik

@mib2berlin

The history file is a database file, you cant compare this with encoding a video.

I definitely can, if the CPU load is comparable The weird part is, again, the main process spends a truckload of CPU cycles to generate 50GB of some data from history only to send it to another process, where all of this... vanishes. Is used for nothing, no network, no drive access, a process with 300MB private bytes and 550MB working space pipes 50GB of something to another process that sits at 100MB of memory and consumes all that traffic without a single interaction that would indicate any willingness to store results of this heavy work anywhere.

I have seen a similar behavior when caching is broken and a loop requests the same piece of data over and over, because it has not been considered worth optimization during development, but then getting that piece proves being expensive enough to make that loop a liability. An example from my work? Going through all locally available files to compare against a list of already processed files that is stored in a JSON, but reading that JSON again on every file... When this code was written, there were barely tens of files, over time that expanded into tens of thousands and JSON file exceeding a megabyte... Well, execution time went from an hour to a few seconds after just changing the code to load that JSON file once before the loop.

In my case the history file goes as far back as 2017, but @shaneb shows that this exact issue does not need a large timespan to occur.

A note on testing history - I went to user profile and moved the History file away to allow Vivaldi to create a fresh one to see the effect, then deleted the "stub" and moved the original file back to recover the full history. Plain and simple, just do the backup in case of a finger slip.

mib2berlin

@szczurnik @shaneb
Hi, I asked in the developer chat if a test file is available 500 MB or more.
@szczurnik
Can you ZIP your history file and upload it in reply of your bug report VB-110453?
I know it is maybe a privacy problem but the testers and developers are not interested in your browsing habits, no time for such things and it is not allowed either.

szczurnik

If history is an open type database like SQLite, I could try removing out entries that raise security concerns for me; not many, so that would be still a hefty file, but still a possible safety relief.

(Well, maybe I could just work from within Vivaldi... seems to be fast and precise enough. A moment, OK, I have to do some work today before going on a private crusade; already delayed by a chillingly noisy fan.)