Crash after browser start
-
@DoctorG Thanks! No problem if it takes time, but in the meantime.... is there a way to redraw/take back the update on the corresponding repos? Or a short Guide to downgrading to the previous version? I rather prefer to use a functional outdated version of vivaldi then to have to switch to (not customized/configured) firefox/chromium whilst waiting for a fix. (Ok, I after typing this.. I think reinstalling from a .deb before the bugged version and putting it on stalled should do it - but then, thats a manual problem of keeping track of "can I update it now" :cheers:) ... Any Advice for us affected users how to deal with the situation in a way that let us use Vivaldi whilst waiting for a fix?
-
@darzi said in Crash after browser start:
Does this indicate that none of the Devs are capable of running a suitable Mac & MacOs or Raspberry Pi 5/500 & RaspiOs
The macOS issue is almost certainly different. For the Linux issue, it is not enough to just run Raspberry Pi 5/500 & RaspiOs as I tested exactly this and no crash.
Anyway, here is a workaround that may work. I cannot test this myself due to not being able to reproduce the bug but at least one user here has confirmed that it seems to work for them. Launch Vivaldi from the terminal like so
vivaldi --js-flags="--nodecommit_pooled_pages"If this fixes it then the issue would appear to be upstream with Chromium
https://issues.chromium.org/issues/378017037
The reason you will not see it with the Chromium bundled with RaspiOs is that it is simply too old (and not secure I might add). You would however see it with other Chromium based browsers that are up to date, such as Brave. You will also see it with Chromium when they get around to updating it.
The Chromium team do not currently want to backport a fix to Chromium 132, so I will see if we can do a workaround for you. In the mean time, please confirm this helps those affected.
-
Thanks @Ruarí ! The workaround works for me on a RPi 5
-
@maels In case you did not know, Vivaldi actually launches via a startup wrapper shell script. I could easily patch it to insert this option on systems running arm64. Later, when we update to a future Chromium with a proper fix, I can just revert the changes to the startup wrapper.
We have a minor update planned for today. Sadly it is too late to get a workaround into that build. That new Vivaldi has already been built and staged pending final testing.
However, it is very likely that we will have another minor update next week, so I can get a workaround in that if more people confirm this works for them.
Additionally I can likely tweak the unofficial flatpak (which I mantain on a personal level) to get this work around in early as it uses its own (custom) start up wrapper script anyway and I can edit that at any time. I do not need a new official build.
-
It's a shame in a way that Chrome do not make an official arm64 build. If they did this would affect them as well and the Chromium team would almost certainly have reacted and backported a fix by now. However it is not so important to them right now because it is only in unofficial Chromium or projects built on that like Vivaldi and Brave.
-
@Ruarí Thanks for the info. I updated the script, so that it now looks like this:
# Note: exec -a below is a bashism. exec -a "$0" "$HERE/vivaldi-bin" "--js-flags=--nodecommit_pooled_pages $@"I am already happy that you found a workaround. Using chromium is not such a good experience
-
@maels Yeah that is basically what I do (but I check the arch first, so this will only happen for arm64 users).
Just a heads up however, when the minor update arrives some time today it will update that wrapper (undoing your change), so you will need to re-apply that. However, you should only need to do it that one extra time, as the following minor update next week would have that present already.
-
Ok, the first minor update to 7.1 is out (7.1.3570.42)
https://vivaldi.com/blog/desktop/minor-update-7-1/
This does not have the fix in the rpm/deb packages, so anyone who need it now would need to manually update the startup wrapper, just as you did.
However, I have tweaked the Flatpak and .Snap (Canonical/Ubuntu) packages already. So anyone using those will already be ok.
-
@Ruarí Jup, starting vivaldi with the parameter you provided is working fine (Pi5)
-
@Ruarí worked for me too, thank you so much! These last few days not using Vivaldi has been a struggle haha. Appreciate the quick fix
-
There is already a fix in the snapshot for anyone in this thread who uses snapshot rather than stable
-
@Ruarí said in Crash after browser start:
...
Anyway, here is a workaround that may work. I cannot test this myself due to not being able to reproduce the bug but at least one user here has confirmed that it seems to work for them. Launch Vivaldi from the terminal like so
vivaldi --js-flags="--nodecommit_pooled_pages"If this fixes it then the issue would appear to be upstream with Chromium
...
The Chromium team do not currently want to backport a fix to Chromium 132, so I will see if we can do a workaround for you. In the mean time, please confirm this helps those affected.Many thanks great detective work finding that work-around which indeed stops the crashes, appreciated.
Am amazed (and somewhat disappointed) that the Chrome team don't make builds for arm64 - all our recent machines use that processor architecture now, in various flavours - hence the interest in stopping crashes on macOs too.
-
@maels said in Crash after browser start:
Thanks @Ruarí ! The workaround works for me on a RPi 5
Yes, confirm RPi 500 (and RPi5) work-around works here too.
-
@Ruarí said in Crash after browser start:
It's a shame in a way that Chrome do not make an official arm64 build. If they did this would affect them as well and the Chromium team would almost certainly have reacted and backported a fix by now. However it is not so important to them right now because it is only in unofficial Chromium or projects built on that like Vivaldi and Brave.
Ah! Did not realise both Vivaldi and Brave are based upon an unofficial project (Chromium on arm64).
We'll have to have a discussion here and decide whether we can continue with Vivaldi (or Brave) - if not for us it looks like a return to Firefox, which Vivaldi was supposed to offer better experience - but sadly (for us) this has not proven to be the case. Sigh.
It could be due to the arm64 aspects but no matter the underlying cause Vivaldi is not reliable and stable enough in practice, currently - we cannot afford the downtime and support issues Vivaldi is currently experiencing, which is a great shame as many aspects of Vivaldi are good, just let down by the lack of stability/reliability.
-
Added the workaround with 7.1.3570.47: https://vivaldi.com/blog/desktop/minor-update-two-7-1/
-
@Ruarí Oh, that will make the ARM people very happy
-
Thx @Ruarí @DoctorG @daniel . Unfortunately vivaldi still crashes after the update (7.1.3570.47 (Stable channel) stable (64-bit) ).
I am not a bash specialist, but removing the double quotes from the script worked for me:Does not work:
[ "arm64" = "arm64" -o "arm64" = "aarch64" ] && VIVALDI_JS_FLAGS='--js-flags="--nodecommit_pooled_pages"'Works:
[ "arm64" = "arm64" -o "arm64" = "aarch64" ] && VIVALDI_JS_FLAGS='--js-flags=--nodecommit_pooled_pages'Is it only me? can someone else please confirm these findings?
-
@maels That might be. Looking again now, yes the quoting is too much. My problem is that I have never reproduced despite having access to several Linux arm64 installs including with Raspberry Pi OS (which I specifically tested), so I did this workaround blind. I did put the fix in the last snapshot but I did not get any comments from affected users confirming if it worked or not
I can tweak it as per your suggestion for a future update. The main issue here is that it is not all arm64 users. Indeed I suspect it is the minority¹ it is just that those who hit it obviously comment. With so few affected there is little feedback.
Anyway I will reopened my internal bug, made your change and will try again.
¹ I am actually a regular arm64 Linux user myself as is one of the other key QA testers and our automated Linux test machines include arm64. None of these machines have shown the issue, thus far.
-
Ok, just commit this to our internal (main) repo
$ git diff d8a6ffbaf083d0c3ed4545f85c445903d2af378d.. diff --git a/installer/linux/common/wrapper b/installer/linux/common/wrapper index 99111c2781..b884aefd42 100755 --- a/installer/linux/common/wrapper +++ b/installer/linux/common/wrapper @@ -61,7 +61,7 @@ if [ "$FFMPEG_FOUND" = NO ]; then fi # Temp workaround for VB-113321 (Vivaldi 7.1 crashes at start on arm64 with SELinux) -[ "@@ARCHITECTURE@@" = "arm64" -o "@@ARCHITECTURE@@" = "aarch64" ] && VIVALDI_JS_FLAGS='--js-flags="--nodecommit_pooled_pages"' +[ "@@ARCHITECTURE@@" = "arm64" -o "@@ARCHITECTURE@@" = "aarch64" ] && VIVALDI_JS_FLAGS='--js-flags=--nodecommit_pooled_pages' export CHROME_VERSION_EXTRA="@@CHANNEL@@"I will get it into a public version when there is next a chance.
-
Ok, I have staged new fixes for the Snap (Canonical package type) and Flatpak. Those I can probably get rolled out this evening but rpm/deb will not be right away as that would required much more steps to get out a new minor update. Mostly it will not happen for a week now.
EDIT: Ok the Snap and Flatpak packages are updated.
