Open Bug 1766849 Opened 3 years ago Updated 2 years ago

Firefox snap crashed with X Window System error 'BadValue'

Categories

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

Firefox 100
Desktop
Linux
defect

Tracking

()

Tracking Status
firefox100 + wontfix
firefox101 --- fix-optional
firefox102 --- affected

People

(Reporter: olivier, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

(initially reported here)

I had the firefox snap crash 3 times yesterday, while running it from the candidate channel (100.0-1) in a wayland session (Ubuntu 22.04). These crashes didn't trigger the crash reporter.
The last time I happened to be running it from a terminal, and I got this:

(firefox:80147): Gdk-WARNING **: 21:44:48.720: The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue'.
  (Details: serial 980422 error_code 2 request_code 53 (core protocol) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

FWIW, I never saw this kind of crash when it was running natively under Wayland, for the past few months (it was only recently reverted to using xwayland because of bug 1725245).

Blocks: snap

Another data point: I saw this crash 3 times yesterday, but it hasn't happened today yet.

Flags: qe-verify?

Removed original comment. Misunderstanding by me.

Is anyone else seeing this besides you that you know of?

I haven't seen other reports of this problem yet. Hopefully it's just me. That said, it just happened again for the first time today (firefox had been running for more than 12 hours).

Component: General → Widget: Gtk
Product: Firefox → Core
Priority: -- → P3

Changing the priority to P1 as the bug is tracked by a release manager for the current beta.
See Triage for Bugzilla for more information.
If you disagree, please discuss with a release manager.

Priority: P3 → P1

(In reply to Olivier Tilloy from comment #0)

(initially reported here)

I had the firefox snap crash 3 times yesterday, while running it from the candidate channel (100.0-1) in a wayland session (Ubuntu 22.04). These crashes didn't trigger the crash reporter.
The last time I happened to be running it from a terminal, and I got this:

(firefox:80147): Gdk-WARNING **: 21:44:48.720: The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue'.
  (Details: serial 980422 error_code 2 request_code 53 (core protocol) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

FWIW, I never saw this kind of crash when it was running natively under Wayland, for the past few months (it was only recently reverted to using xwayland because of bug 1725245).

Hi Olivier!
We are attempting to reproduce your reported crash which does not log a crash report.

So far, no kind of crashes was reproduced in Ubuntu 22.04 LTS set up with:

  1. XDG_CURRENT_DESKTOP = wayland + Firefox session Window Protocol = xwayland (also with wayland)
  2. XDG_CURRENT_DESKTOP = gnome + Firefox session Window Protocol = xwayland (also with wayland)

Could you answer some questions, please?

  1. What does the command "echo $XDG_CURRENT_DESKTOP" show you in the terminal?
  2. How did you open the Firefox build from the terminal, exactly? Any special arguments to the command?
  3. Can you confirm that your crashes occurred only when the Firefox session had "xwayland" as its Window Protocol? (seen in about:support)
  4. When the crashes occurred, did the "Crash Reporter" appear after the crash? (window seen in here )
  5. Most importantly... Can you tell us what you were doing when the crash occurred? What kind of content has been used?
  6. Does it still reproduce on your side? (on release candidate 1 or 2)

Thank you for your contribution!

Flags: needinfo?(olivier)
  1. What does the command "echo $XDG_CURRENT_DESKTOP" show you in the terminal?
ubuntu:GNOME
  1. How did you open the Firefox build from the terminal, exactly? Any special arguments to the command?
snap run firefox
  1. Can you confirm that your crashes occurred only when the Firefox session had "xwayland" as its Window Protocol? (seen in about:support)

Yes, I'm running version 100.0-1 from the candidate channel, which forces xwayland.

  1. When the crashes occurred, did the "Crash Reporter" appear after the crash? (window seen in here )

No, no crash reporter. All firefox windows abruptly closed, and that was the end of it.

  1. Most importantly... Can you tell us what you were doing when the crash occurred? What kind of content has been used?

IIRC the first few crashes I was watching videos on youtube when the crash happened. I was going to write that this seemed to be a common denominator, but then I just got one other instance of this crash 5 minutes ago when I was switching from one pinned tab to the other (gmail.com, if it matters). There was no video playback running/paused in any of the open tabs.

  1. Does it still reproduce on your side? (on release candidate 1 or 2)

Yes, as I wrote above, it just happened again, on 100.0-1. Not very frequently (that was the first crash of the day after using the browser extensively for ~8 hours), but it does happen every day.

Flags: needinfo?(olivier)

This just happened again when starting playback of a youtube video in a private window.
As I was running firefox from a terminal, I can confirm the error is the same:

(firefox:55318): Gdk-WARNING **: 15:26:34.304: The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue'.
  (Details: serial 151807 error_code 2 request_code 53 (core protocol) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

53 seems to be CreatePixmap:
https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html

CreatePixmap
1 53 opcode

Please open about:support, click on "Copy text to clipboard" and paste it here.
(=Which GPU, display resolution, custom prefs, environment variables do you have?)

I found these:

Attached file raw output of about:support (deleted) —

Final QA test results:

No "natural" crash was reproduced while stress testing 2 different systems with the configurations stated above for about 5 hours each.
We've stress tester it with complex animations, HD video streaming, webrtc calling, common high consuming websides like facebook, gmail, youtube, web benchmark stress tests and others.

The closest reproduction to the reported behavior we could observe is:

  1. Open RC2 with wayland Window Protocol
  2. Load an OOM crash test page (from https://bugzilla.mozilla.org/show_bug.cgi?id=1677364)
    Result: **Notice that the browser crashes without displaying the Crash Reporter window and without having a crash log saved in about:crashes. ** Though, this does not leave the stated error in the terminal.
    These steps were both tested in:
  • Ubuntu 22 + gnome and Firefox + wayland
  • Ubuntu 22 + wayland and Firefox + wayland
  • Ubuntu 22 + X11 and Firefox + X11

Another quite worrying situation:

  1. Open RC2 with xwayland Window Protocol
  2. Load an OOM crash test page (from https://bugzilla.mozilla.org/show_bug.cgi?id=1677364)
    Result: Notice that the WHOLE SYSTEM crashes; the system restarts.
    These steps were both tested in:
  • Ubuntu 22 + wayland and Firefox + xwayland
  • Ubuntu 22 + wayland and Firefox + xwayland

AFTER the last 2 comments, I've removed all firefoxes from my system and reinstalled the candidate channel with snap; and I've found another similar situation; Steps:

  1. Open the terminal
  2. Install firefox candidate using snap (sudo snap install firefox --candidate)
  3. type and submit: export MOZ_ENABLE_WAYLAND=0
  4. type and submit: snap run firefox
    Result: Upon only opening it, it crashed and a similar error got displayed (having message "BadAlloc" instead of the reported "BadValue").

Terminal information:
daniel.bodea@P5637:~$ snap run firefox
Importing existing firefox profiles from /home/daniel.bodea/.mozilla/firefox
Found default profile: arnx1uav.shykjedytkye
Import done in 22,000 s
Gtk-Message: 17:11:19.087: Failed to load module "canberra-gtk-module"
Gtk-Message: 17:11:19.169: Failed to load module "canberra-gtk-module"
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
(firefox:17702): Gdk-WARNING **: 17:11:22.229: The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc'.
(Details: serial 456 error_code 11 request_code 146 (unknown) minor_code 7)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

This issue does not occur if in step 3, you type and submit: export MOZ_ENABLE_WAYLAND=1.

I should also mention that we couldn't reproduce it using the information in comment 7.
I am not sure how I should continue testing this. Please NI me if further testing is needed, but provide some direction.

Thank you.

(I think using wayland in the ubuntu wayland sessions is probably reasonable fwiw)

Please test if the BadValue crash also occurs with Snap on Gnome X11.

IMHO, it's better to keep using MOZ_ENABLE_WAYLAND on Wayland, please consider reverting https://git.launchpad.net/~mozilla-snaps/+git/firefox-snap/commit/?id=4f3ad5cdc390fedab5db6e2d9a062a2c3bd88474 (bug 1725245 comment 19).

bug 1725245 comment 10 gave green light on keeping Wayland on Ubuntu. It has been enabled by default on Fedora and Ubuntu for a long time.

(Partly offtopic side note: Better use Wayland than Xwayland on Nvidia.)

bug 1749174 enabled MOZ_ENABLE_WAYLAND for Nightly and Early Beta.

Wayland pain points (bug 1752398):

  • bug 1695591 and its dependencies == Consider limiting max widget size on Wayland to prevent crashing WebRender because of invalid large size.
  • bug 1739622: PiP window can't be resized when grabbing "the vertical or horizontal margins (not the corners)"

(In reply to Olivier Tilloy from comment #7)

This just happened again when starting playback of a youtube video in a private window.
As I was running firefox from a terminal, I can confirm the error is the same:

Can you reproduce your crash with an official mozilla build and not a snap? Thanks

Flags: needinfo?(olivier)

I have the same error after upgrading from ubuntu 20.04 > 21 > 22.04

(In reply to Pascal Chevrel:pascalc from comment #13)

Can you reproduce your crash with an official mozilla build and not a snap? Thanks

I've been running an official mozilla build in parallel all day long, and no crash.
I have also been running the snap from the candidate channel with MOZ_ENABLE_WAYLAND=1 for the past two days, and no crash.

So the crash appears to be snap-specific, and obviously (because it's an X Window System error) when running as an XWayland client (which is in the current state of affairs the default).

Flags: needinfo?(olivier)

For me the bug occured consistently on starting the app (installed via snap on 22.04) , so I literally could not use it...

However, I just found switching to i3, Firefox worked!
So for now this is my work round.

I had tried removing all addons and themes and doing a reset but nothing would allow me to start firefox, unless I used the --verbose flag.

One telling issue is when starting Firefox in i3 it does not render in the entire window area initially, you have to fullscreen the app

Hope this info helps!

(In reply to diversemix from comment #17)

For me the bug occured consistently on starting the app (installed via snap on 22.04) , so I literally could not use it...

Just to double-check, this was the exact same BadValue error, with error_code 2 and request_code 53 ?

Flags: needinfo?(diversemix)

(In reply to Sylvestre Ledru [:Sylvestre] from comment #14)

And especially with "our" version of the snap packages:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/fT3o7pIcT5G-vHsmVEK5mA/runs/0/artifacts/public/build/target.snap

I just installed that version, and it runs as a native Wayland client by default, so it won't be affected.
And it won't run at all when forcing MOZ_ENABLE_WAYLAND=0.

Depends on: wayland-stable

I dont know why wayland-stable was added, it's an XWayland issue

No longer depends on: wayland-stable

(In reply to Alexandre LISSY :gerard-majax from comment #20)

I dont know why wayland-stable was added, it's an XWayland issue

Xwayland would become irrelevant by shipping Wayland.

(In reply to Darkspirit from comment #21)

(In reply to Alexandre LISSY :gerard-majax from comment #20)

I dont know why wayland-stable was added, it's an XWayland issue

Xwayland would become irrelevant by shipping Wayland.

Unfortunately, it does not seems to be planned for any near-future.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:stransky, since the bug has high priority and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(diversemix) → needinfo?(stransky)
Flags: needinfo?(stransky)

Changing qe-verify? to qe-verify+.

Flags: qe-verify? → qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: