Closed Bug 1898476 Opened 9 months ago Closed 7 months ago

Firefox crashes on Wayland with Explicit Sync on Nvidia

Categories

(Core :: Widget: Gtk, defect, P1)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 128
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
130 Branch
Tracking Flags:
Tracking Status
thunderbird_esr128 --- fixed
firefox-esr115 --- wontfix
firefox-esr128 130+ fixed
firefox128 --- wontfix
firefox129 --- wontfix
firefox130 --- fixed

People

(Reporter: Vash63, Assigned: stransky)

References

(Blocks 3 open bugs)

Details

(Keywords: crash, topcrash-thunderbird, wayland)

Attachments

(7 files)

Bug 1898476 [Wayland] Move MozContainerSurfaceLock from MozContainerWayland to MozContainerSurfaceLock module r?emilio
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-esr128+
Details | Review
Bug 1898476 [Wayland] Provide surface lock by GtkCompositorWidget r?emilio
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-esr128+
Details | Review
Bug 1898476 [Wayland] Lock Wayland surface before Swap buffers in RenderCompositorEGL r?emilio,jgilbert
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-esr128+
Details | Review
var_log_messages_firefox_crash
16.33 KB, text/plain
Details
var_log_messages_firefox_crash
16.33 KB, text/plain
Details
var_log_messages_firefox_crash
16.33 KB, text/plain
Details
Report (as legible text) from about:support
50.06 KB, text/plain
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36

Steps to reproduce:

  1. Installed the new Nvidia 555 series drivers
  2. Used Gnome 46.1 or another compositor with Explicit Sync support (kwin w/ some patches)
  3. Run Firefox

Actual results:

Firefox crashes with:

$ firefox-nightly/firefox
[GFX1-]: Wayland protocol error: wp_linux_drm_syncobj_surface_v1@59: error 4: No Acquire point provided

ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::GenerateDump cloned child 43927
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.

Expected results:

Firefox runs

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Blocks: wayland
Priority: -- → P3

For me, the error message looks slightly different:

$ firefox
[GFX1-]: Wayland protocol error: wp_linux_drm_syncobj_surface_v1@75: error 4: explicit sync is used, but no acquire point is set

ExceptionHandler::GenerateDump cloned child 118029
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Exiting due to channel error.

However, I think it is the same error.

Troubleshoot mode works fine, normal mode (also without addons) crashes

Blocks: wr-nv-linux
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

Saw this when discussing this online: https://invent.kde.org/plasma/kwin/-/merge_requests/5683

Not sure it helps here but it was causing QMplay2 on mesa w/ RADV (presumably this uses Vulkan somewhere?) to crash with:
"wp_linux_drm_syncobj_surface_v1@107: error 4: explicit sync is used, but no acquire point is set"

Maybe my bug is actually caused by Mutter then? @konrad are you on KDE, and if so can you try the above patch (or -git version of kwin since it's merged)?

(In reply to konrad from comment #2)

For me, the error message looks slightly different:

$ firefox
[GFX1-]: Wayland protocol error: wp_linux_drm_syncobj_surface_v1@75: error 4: explicit sync is used, but no acquire point is set

ExceptionHandler::GenerateDump cloned child 118029
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Exiting due to channel error.

However, I think it is the same error.

Troubleshoot mode works fine, normal mode (also without addons) crashes

I re-tested this on the KDE 6.1 beta w/ explicit sync and can confirm the error changes to match yours:

[GFX1-]: Wayland protocol error: wp_linux_drm_syncobj_surface_v1@66: error 4: explicit sync is used, but no acquire point is set

So it seems the error is from the compositor, not Firefox?

There is an issue about this on NVIDIA's egl-wayland repo, and it seems that the Firefox's behavior is problematic.

Duplicate of this bug: 1899000
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash, wayland
See Also: → https://github.com/NVIDIA/egl-wayland/issues/110#issuecomment-2132241753
Flags: needinfo?(stransky)

In the GitLab thread about the sync protocol, this is mentioned:

With firefox I'm seeing something some extra frame and commit events get injected into my attach+syncpoints+commit cycle:

[2365871.993]  -> wl_surface@63.attach(wl_buffer@67, 0, 0)
[2365872.013]  -> wl_surface@63.frame(new id wl_callback@65)  <<<<<< This gets added from firefox
[2365872.019]  -> wl_surface@63.commit()
[2365872.039]  -> wp_linux_drm_syncobj_surface_v1@55.set_acquire_point(wp_linux_drm_syncobj_timeline_v1@59, 0, 252)
[2365872.046]  -> wp_linux_drm_syncobj_surface_v1@55.set_release_point(wp_linux_drm_syncobj_timeline_v1@70, 0, 84)
[2365872.051]  -> wl_surface@63.damage(0, 0, 1280, 972)
[2365872.057]  -> wl_surface@63.commit()                      <<<<<< No buffer attach in this commit
[2365872.062]  -> wl_display@1.sync(new id wl_callback@77)
[2365872.139] wl_buffer@73.release()
[2365872.234] wl_display@1.error(wl_surface@63, 3, "explicit sync point set but no buffer attached for surface 63")

The issue has also been reported on the Mutter GitLab.

According to the discussions on GitHub about this, Firefox has a thread trying to write to a surface allocation that another thread has not created yet, resulting in behavior that is not allowed by the sync protocol. There is a log from Firefox and a log from Thunderbird of the issue happening.

See Also: → https://bugs.kde.org/show_bug.cgi?id=487571#c1

Yes, we'd need to sync write to wl_surface. Main issue is to share lock between GL and widget code.

Is there any interim fix apart from downgrading explicit sync possible? Firefox has been crashing constantly with kwin and nvidia driver 555.

Is there any interim fix

You can run Firefox under Xwayland to work around the issue with the environment variable MOZ_ENABLE_WAYLAND=0. I have copied the desktop file for Firefox to my user's ~/.local/share/applications so that I could set that variable automatically when launching Firefox.

You can run Firefox under Xwayland to work around the issue with the environment variable MOZ_ENABLE_WAYLAND=0. I have copied the desktop file for Firefox to my user's ~/.local/share/applications so that I could set that variable automatically when launching Firefox.

That worked, thank you! I just added it to /etc/environment and restarted.

Is there an update that is expected to resolve this? I would rather not run using xwayland as it seems to degrade performance significantly.

(In reply to jon from comment #12)

Is there an update that is expected to resolve this? I would rather not run using xwayland as it seems to degrade performance significantly.

For me Firefox reverted to software rendering in Xwayland mode, with significantly degraded performance. Setting gfx.webrender.all=true in about:config got it back to hardware rendering and got me mostly back to normal performance.

(In reply to Karl Erik Hofseth from comment #13)

For me Firefox reverted to software rendering in Xwayland mode, with significantly degraded performance. Setting gfx.webrender.all=true in about:config got it back to hardware rendering and got me mostly back to normal performance.

Unfortunately this didn't seem to work for me. Half of the text won't render for some reason.

(In reply to jon from comment #14)

(In reply to Karl Erik Hofseth from comment #13)

For me Firefox reverted to software rendering in Xwayland mode, with significantly degraded performance. Setting gfx.webrender.all=true in about:config got it back to hardware rendering and got me mostly back to normal performance.

Unfortunately this didn't seem to work for me. Half of the text won't render for some reason.

The reason it does that is because by default it is actually using the zink egl provider (can verify on about:support).
The way to workaround it is add __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/10_nvidia.json

This will make firefox switch to GLX basically because Nvidia EGL in xwayland is currently broken but you will get hardware acceleration and no broken fonts (the fonts issue is somehow related to subpixel rendering when using zink as I figured I can remedy the problem somewhat by flipping subpixel rendering option in KDE to something else and then back to RGB (in the case of my monitors) or None).

Still this workaround, while it provides basic hardware acceleration, it comes with a lot of caveats that I have encountered. Main ones of the top of my head is that video hardware acceleration is impossible and there's no dmabuf support.

Considering the performance issues on xwayland this should probably be higher priority as a release nvidia driver with explicit sync is coming soon and it will break wayland firefox on every system with nvidia proprietary driver.

(In reply to nodensntt from comment #15)

Thanks for the insight. I agree this should absolutely be a high priority.

Is there no ETA for a bug fix for this? I'm considering the option of using chromium as my daily driver since I'd want all my programs to be Wayland native, and this bug should be a higher priority since it breaks the experience of the browser. Firefox is better than chromium for me, but this bug is really grinding my gears. I appreciate what the developers are doing to give us an amazing experience and i thank you all for that as well.

I agree as to the potential high priority on this bug, as it makes Firefox completely unusable on the new Nvidia drivers.

I'm not sure if this is also related to this issue, but since using the v555 drivers and plasma 6.1, I've been encountering occasional stuttering in full-screen video playback, i.e. the Video runs perfectly fine, and then the Framerate seems to dip considerably until it catches back up a few moments later. This happens in a clean-profile as well and notably does not seem to be related to video buffering.

The issue is exclusive to Firefox and does not happen in chromium based browser - I'm fairly certain it is related to explicit sync support but I'm not quite certain, let me know if there is an existing report for this issue as well (could not find one) or if I should open a separate issue for this

(In reply to fynnbwdt from comment #19)

I'm not sure if this is also related to this issue, but since using the v555 drivers and plasma 6.1, I've been encountering occasional stuttering in full-screen video playback, i.e. the Video runs perfectly fine, and then the Framerate seems to dip considerably until it catches back up a few moments later. This happens in a clean-profile as well and notably does not seem to be related to video buffering.

The issue is exclusive to Firefox and does not happen in chromium based browser - I'm fairly certain it is related to explicit sync support but I'm not quite certain, let me know if there is an existing report for this issue as well (could not find one) or if I should open a separate issue for this

PS: Notably, it also does not happen when the video is not in full-screen. This happens only for full-screen video playback

Assignee: nobody → stransky
Status: NEW → ASSIGNED
Flags: needinfo?(stransky)

Thanks Martin. We know you will do a great work in fixing this problem. Looking forward for a better Linux experience!

Duplicate of this bug: 1905762

This is now impacting the stable Nvidia drivers since the release branch now supports explicit sync. Are the patches just needing review/testing? Firefox is fairly large so I don't usually built it myself but I'll see if I can test this in the coming days.

Nvidia 555.58 driver, Fedora 40, KDE Plasma 6.1.1, Wayland.

Google web services (docs, drive) crash firefox when hardware acceleration enabled. Crashes do not occur when hardware acceleration is disabled in Firefox 127.0.2.

(In reply to Vash63 from comment #26)

This is now impacting the stable Nvidia drivers since the release branch now supports explicit sync. Are the patches just needing review/testing? Firefox is fairly large so I don't usually built it myself but I'll see if I can test this in the coming days.
Nvidia 555.58 driver, Fedora 40, KDE Plasma 6.1.1, Wayland.

Google web services (docs, drive) crash firefox when hardware acceleration enabled. Crashes do not occur when hardware acceleration is disabled in Firefox 127.0.2.

Yes. It's only related in how the NVIDIA driver communicates with the compositor. I found out that Firefox works just fine under Wayland using compositors without the linux-drm-syncobj-v1 protocol, like Hyprland. Might be because the compositor is not forcing buffer synchronization since it doesn't supports it. I'm not a programmer so i might be wrong, but what I do know is that this bug needs to be fixed and merged as soon as possible since it breaks the experience of the user. BTW you can use XWayland as a workaround if you want

Regarding to Xwayland, at least with my setup (mutter 46.3.1, Xwayland 24.1.0, nvidia 555.58.02), using Firefox inside Xwayland it won't crash but all windows contents are totally corrupted, leaving Firefox unable to be used with this combination either. If I'm not mistaken Xwayland also have implemented support for linux-drm-syncobj-v1, even that I'm not sure if this is related with this other issue, but other EGL apps work well under Xwayland.

Also, I noticed that at least in Firefox 128.0b9, using NVIDIA and with selected the "recommended" performance settings, it now automatically disables the hardware compositing (Acceleration blocked by platform), allowing the usage of Firefox under Wayland without crashing.
I assume this have been added as a temporally workaround.

Thanks.

(In reply to Pau RE from comment #29)

Regarding to Xwayland, at least with my setup (mutter 46.3.1, Xwayland 24.1.0, nvidia 555.58.02), using Firefox inside Xwayland it won't crash but all windows contents are totally corrupted, leaving Firefox unable to be used with this combination either. If I'm not mistaken Xwayland also have implemented support for linux-drm-syncobj-v1, even that I'm not sure if this is related with this other issue, but other EGL apps work well under Xwayland.

Also, I noticed that at least in Firefox 128.0b9, using NVIDIA and with selected the "recommended" performance settings, it now automatically disables the hardware compositing (Acceleration blocked by platform), allowing the usage of Firefox under Wayland without crashing.
I assume this have been added as a temporally workaround.

Read https://bugzilla.mozilla.org/show_bug.cgi?id=1898476#c15

(In reply to nodensntt from comment #30)

Read https://bugzilla.mozilla.org/show_bug.cgi?id=1898476#c15

Hello nodensntt,

This is not my case, since I didn't even have any Mesa drivers installed at all.
But I believe this isn't related with this issue, just another inconvenience that impede to use Xwayland as a workaround.
My intention was to just point out that using Xwayland isn't an option either (at least with the NVIDIA drivers).

For me I have already disabled hardware compositing and it works okish under Wayland, so no big deal here, until this issue gets fixed.

But to dig into the details, using NVIDIA EGL under Xwayland to me it creates a fully corrupted image window (and not only some texts) and it can get fixed by resizing the window. And every time it gets that corrupted again, one need to re-resize the window to fix the window contents.
I also tried forcing using the egl_vendor.d/10_nvidia.json with my correct path and it fails the same way.

By forcing to use Zink, it will work out of the box.
To do so I had to install Mesa and I added this environment variables:

__EGL_VENDOR_LIBRARY_FILENAMES=/usr/lib/x86_64-linux-gnu/GL/glvnd/egl_vendor.d/50_mesa.json
MESA_LOADER_DRIVER_OVERRIDE=zink
GALLIUM_DRIVER=zink

But as you said using Zink works by failing back to software render, so I believe its easier to just disable hardware compositing manually and use Wayland directly.

In any case, thanks for the reference anyway.

(In reply to Pau RE from comment #31)

But to dig into the details, using NVIDIA EGL under Xwayland to me it creates a fully corrupted image window (and not only some texts) and it can get fixed by resizing the window. And every time it gets that corrupted again, one need to re-resize the window to fix the window contents.
I also tried forcing using the egl_vendor.d/10_nvidia.json with my correct path and it fails the same way.

The thing is that Nvidia EGL under Xwayland is not working. At all. It is broken entirely. Can you check what exactly firefox says in about:support that it is using? It should be using GLX under Xwayland. Firefox should be automatically switching to GLX when using the nvidia provider after detecting that EGL is broken.

My mistake, I was looking it wrong when testing other EGL applications.
So its true about EGL not working in Xwayland, they switch to use Zink or software rendering when possible with error messages like:

mpv:     libEGL warning: egl: failed to create dri2 screen
firefox: [GFX1-]: glxtest: libEGL no display

Also with my tests the rendering corruption only happen when firefox is using GLX with Xwayland with NVIDIA.
I also discovered that having MOZ_ENABLE_WAYLAND=0 will use GLX and hardware compositing with the rendering corruption bug.
But having no environment variable or having it set to 1, while also disabling Wayland access (while allowing access to Xwayland) it always fallback to both software rendering and compositing. Having no rendering issues, but poor performance.
Not to be a problem, it's just that I find it a curiosity. :)

Thanks for the information.

Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/480f3f701046 [Wayland] Move MozContainerSurfaceLock from MozContainerWayland to MozContainerSurfaceLock module r=emilio https://hg.mozilla.org/integration/autoland/rev/69e7c8a0cca3 [Wayland] Provide surface lock by GtkCompositorWidget r=emilio https://hg.mozilla.org/integration/autoland/rev/72c5ebe1a9da [Wayland] Lock Wayland surface before Swap buffers in RenderCompositorEGL r=emilio
Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/3e6bd6c75492 [Wayland] Move MozContainerSurfaceLock from MozContainerWayland to MozContainerSurfaceLock module r=emilio https://hg.mozilla.org/integration/autoland/rev/fc9ffe1ae7ee [Wayland] Provide surface lock by GtkCompositorWidget r=emilio https://hg.mozilla.org/integration/autoland/rev/b56930a4d8bc [Wayland] Lock Wayland surface before Swap buffers in RenderCompositorEGL r=emilio
Flags: needinfo?(stransky)
Priority: P3 → P2

Yes, I see the failures on Wayland try although I don't see them locally. Will look at it.

Flags: needinfo?(stransky)

After pulling updates on Fedora 40, under KDE plasma 6.1 wayland with kernel 6.9.8-200.fc40.x86_64, nvidia 555.58.02 and Firefox 128.0-1.fc40, I can replicate Pau RE's report above. GLX is now also unusable under xwayland with heavy graphical corruption.
Only way to get firefox to display properly is to run with WebRender set to software.
So the current situation is that we have no hardware acceleration possible at all with 555 nvidia drivers at this point.

(In reply to nodensntt from comment #39)

After pulling updates on Fedora 40, under KDE plasma 6.1 wayland with kernel 6.9.8-200.fc40.x86_64, nvidia 555.58.02 and Firefox 128.0-1.fc40, I can replicate Pau RE's report above. GLX is now also unusable under xwayland with heavy graphical corruption.
Only way to get firefox to display properly is to run with WebRender set to software.
So the current situation is that we have no hardware acceleration possible at all with 555 nvidia drivers at this point.

Fedora ships the patch downstream in latest Firefox 128.0 update - https://bodhi.fedoraproject.org/updates/FEDORA-2024-f9e8f7d3a7 - so it should work fine if you use Fedora provided packages. I sorted out the issues here and will push the patches today and we may also backport them to beta.

Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/f9323daf7abe [Wayland] Move MozContainerSurfaceLock from MozContainerWayland to MozContainerSurfaceLock module r=emilio https://hg.mozilla.org/integration/autoland/rev/a264ff9e9f6f [Wayland] Provide surface lock by GtkCompositorWidget r=emilio https://hg.mozilla.org/integration/autoland/rev/eb230ecdf8eb [Wayland] Lock Wayland surface before Swap buffers in RenderCompositorEGL r=emilio
status-firefox128: --- → affected
status-firefox129: --- → affected
status-firefox130: --- → affected
Flags: needinfo?(stransky)
There's still something not right. I'm still getting crashes when running native wayland. Although now it may take a 30 seconds up to a couple of minutes in order to crash. Previously it was immediate:
There's still something not right. I'm still getting crashes when running native wayland. Although now it may take a 30 seconds up to a couple of minutes in order to crash. Previously it was immediate:
There's still something not right. I'm still getting crashes when running native wayland. Although now it may take a 30 seconds up to a couple of minutes in order to crash. Previously it was immediate:
(In reply to Martin Stránský [:stransky] (ni? me) from comment #40) > (In reply to nodensntt from comment #39) > > After pulling updates on Fedora 40, under KDE plasma 6.1 wayland with kernel 6.9.8-200.fc40.x86_64, nvidia 555.58.02 and Firefox 128.0-1.fc40, I can replicate Pau RE's report above. GLX is now also unusable under xwayland with heavy graphical corruption. > > Only way to get firefox to display properly is to run with WebRender set to software. > > So the current situation is that we have no hardware acceleration possible at all with 555 nvidia drivers at this point. > > Fedora ships the patch downstream in latest Firefox 128.0 update - https://bodhi.fedoraproject.org/updates/FEDORA-2024-f9e8f7d3a7 - so it should work fine if you use Fedora provided packages. I sorted out the issues here and will push the patches today and we may also backport them to beta. Unsure where i should be reporting (since fedora's firefox package now differs from vanilla), but since you seem to be the one who pushed the patch, the explicit sync crash is fixed, but another crash takes it's place: ``` Assertion 'close_nointr(fd) != -EBADF' failed at src/basic/fd-util.c:75, function safe_close(). Aborting. Redirecting call to abort() to mozalloc_abort ExceptionHandler::GenerateDump attempting to generate:/home/amethyst/.mozilla/firefox/rvy1k4oc.default-release-1720218284033/minidumps/1ffe9ea9-4671-bf1f-69d3-7362d3186905.dmp ExceptionHandler::GenerateDump cloned child 46480 ExceptionHandler::SendContinueSignalToChild sent continue signal to child ExceptionHandler::WaitForContinueSignal waiting for continue signal... ExceptionHandler::GenerateDump minidump generation succeeded ``` I'm unable to reproduce the symptoms mentioned by nodensntt and Pau Re, zero graphical corruption. Fedora 40, Latest firefox package (128.0-1.fc40, 20240709131756) Worth mentioning that i have a few about:config options set, for hardware decoding on web videos and etc. Attaching report from about:support

Sorry for the triple upload and noise but I kept getting a popup error while pasting in the comment box as a code block and choosing to upload which apparently also posted the written text so far thrice without updating the UI.

Also in dmesg during the crash:

[  381.010425] [drm:nv_drm_semsurf_fence_wait_ioctl [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00006500] Attempt to wait on invalid sync FD: 235
[  493.641779] [drm:nv_drm_semsurf_fence_wait_ioctl [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00006500] Attempt to wait on invalid sync FD: 226
[  587.611001] show_signal_msg: 52 callbacks suppressed
[  587.611006] WebExtensions[12032]: segfault at 0 ip 00007f91c214c5ca sp 00007ffe3fcc1e80 error 6 in libxul.so[7f91c1663000+4dfb000] likely on CPU 15 (core 25, socket 0)
[  587.611026] Code: d4 05 49 89 04 24 31 d2 89 14 25 00 00 00 00 0f 0b 48 8d 35 f6 61 9d 05 48 89 e7 e8 d0 c8 bb 01 48 8b 04 24 49 89 04 24 31 c0 <89> 04 25 00 00 00 00 0f 0b f3 0f 1e fa 48 89 f8 48 85 f6 74 0f 48

(In reply to rockyamethyst2 from comment #45)

I'm unable to reproduce the symptoms mentioned by nodensntt and Pau Re, zero
graphical corruption.

Graphical corruption occurs only when run on xwayland via MOZ_ENABLE_WAYLAND=0 and using GLX (not software render).

Regressions: 1907219

Please file a new bugs for the remaining issues. I don't have NVIDIA hardware so I can't test it reliably.

https://crash-stats.mozilla.org/report/index/11556c48-552e-4279-a8ec-a0b3c0240713 Thunderbird, user states "Nvidia 555 on Wayland with explicit sync"

This is #1 crash for Thunderbird 128.0 esr, so the patch is urgently needed on esr

Blocks: tb128found
Keywords: topcrash-thunderbird

(In reply to Wayne Mery (:wsmwk) from comment #50)

https://crash-stats.mozilla.org/report/index/11556c48-552e-4279-a8ec-a0b3c0240713 Thunderbird, user states "Nvidia 555 on Wayland with explicit sync"

This is #1 crash for Thunderbird 128.0 esr, so the patch is urgently needed on esr

Also take Bug 1907511 please.

Priority: P2 → P1
Regressed by: 1908825
Duplicate of this bug: 1908816
Keywords: regression
No longer regressed by: 1908825
See Also: → 1908825
No longer duplicate of this bug: 1908816

It would be great if we could get some verification that these patches improved the situation for Nightly users. I know there's some push to backport these changes more aggressively and having some confidence that they've made things better would certainly help make an informed decision in that respect.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #53)

It would be great if we could get some verification that these patches improved the situation for Nightly users. I know there's some push to backport these changes more aggressively and having some confidence that they've made things better would certainly help make an informed decision in that respect.

It greatly improved the situation for me, from 100% crashing within the first 10 seconds of opening the browser to being "mostly" stable. I still get some crashes in Wayland that don't occur with XWayland, which I did not get prior to explicit sync, but they are now difficult to reproduce.

Status: RESOLVED → VERIFIED

I can't reproduce this at all on 2024-07-23, marked it as verified. If there is any instability left it's probably something else.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #53)

It would be great if we could get some verification that these patches improved the situation for Nightly users. I know there's some push to backport these changes more aggressively and having some confidence that they've made things better would certainly help make an informed decision in that respect.

Bug 1908825 as follow up is being investigated but I need more logging.

From recent logs it looks like we fixed all places where we need to lock the surface commits and rest of the crashes comes from third party code (according to missing log entries from Firefox).

But I'll be sure when I get logs from https://bugzilla.mozilla.org/show_bug.cgi?id=1908825#c23

Keywords: regression

Comment on attachment 9409541 [details]
Bug 1898476 [Wayland] Move MozContainerSurfaceLock from MozContainerWayland to MozContainerSurfaceLock module r?emilio

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Doesn't work under Wayland/NVIDIA with explicit Sync enabled.
  • User impact if declined: Doesn't work under Wayland/NVIDIA with explicit Sync enabled.
  • Fix Landed on Version:
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): Add another mutex/lock before we commit to wayland surface or swap GL buffer. Fairly straightforward patch, already shipped downstream on Fedora and on Nightly/Beta without regressions.
Attachment #9409541 - Flags: approval-mozilla-esr128?

Comment on attachment 9409542 [details]
Bug 1898476 [Wayland] Provide surface lock by GtkCompositorWidget r?emilio

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration:
  • User impact if declined:
  • Fix Landed on Version:
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky):
Attachment #9409542 - Flags: approval-mozilla-esr128?

Comment on attachment 9409543 [details]
Bug 1898476 [Wayland] Lock Wayland surface before Swap buffers in RenderCompositorEGL r?emilio,jgilbert

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration:
  • User impact if declined:
  • Fix Landed on Version:
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky):
Attachment #9409543 - Flags: approval-mozilla-esr128?

(In reply to Martin Stránský [:stransky] (ni? me) from comment #57)

  • Why is the change risky/not risky? (and alternatives if risky): Add another mutex/lock before we commit to wayland surface or swap GL buffer. Fairly straightforward patch, already shipped downstream on Fedora and on Nightly/Beta without regressions.

There was a regression with bug 1907511 so presumably that would need to be uplifted as well.

(In reply to Mathew Hodson from comment #60)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #57)

  • Why is the change risky/not risky? (and alternatives if risky): Add another mutex/lock before we commit to wayland surface or swap GL buffer. Fairly straightforward patch, already shipped downstream on Fedora and on Nightly/Beta without regressions.

There was a regression with bug 1907511 so presumably that would need to be uplifted as well.

Yes, we need to take it too.

Comment on attachment 9409541 [details]
Bug 1898476 [Wayland] Move MozContainerSurfaceLock from MozContainerWayland to MozContainerSurfaceLock module r?emilio

Approved for 128.2esr.

Attachment #9409541 - Flags: approval-mozilla-esr128? → approval-mozilla-esr128+
Attachment #9409542 - Flags: approval-mozilla-esr128? → approval-mozilla-esr128+
Attachment #9409543 - Flags: approval-mozilla-esr128? → approval-mozilla-esr128+
See Also: → 1911055
Duplicate of this bug: 1915581
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: