Bug 762035 – www-client/firefox-84*[wayland] crashes

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Michael Hofmann 2020-12-28 00:06:54 UTC]

www-client/firefox-84* crashes in Wayland mode:

  # time firefox
  Segmentation fault (core dumped)

  real    0m0.638s
  user    0m0.276s
  sys     0m0.171s

But it works in X11 mode:

  MOZ_DISABLE_WAYLAND=1 firefox

See: https://forums.gentoo.org/viewtopic-t-1126235.html

Reproducible: Always

[Comment 1 Michael Hofmann 2020-12-28 00:11:47 UTC]

Created attachment 679922 [details]
emerge --info firefox

[Comment 2 Jonas Stein 2020-12-28 00:13:13 UTC]

please link the ticket in the forum too, to prevent duplicates.
I note that firefox bin works fine for you.
Try to add more details.

[Comment 3 Michael Hofmann 2020-12-28 00:23:46 UTC]

I'll try to provide a backtrace. I just started to re-emerge Firefox with debugsyms and installsources.

[Comment 4 Michael Hofmann 2020-12-28 02:05:22 UTC]

Created attachment 679925 [details]
GDB backtrace after crash in Wayland mode

[Comment 5 Michael Hofmann 2020-12-28 03:51:35 UTC]

The error seems to occur in firefox-84.0.1/toolkit/components/remote/nsRemoteService.cpp:172

Below is line 172 and the surrounding function.
Line 172 is marked with '<====='


void nsRemoteService::StartupServer() {
  if (mRemoteServer) {
    return;
  }

  if (mProfile.IsEmpty()) {
    return;
  }

#ifdef MOZ_WIDGET_GTK
  bool useX11Remote = GDK_IS_X11_DISPLAY(gdk_display_get_default());

#  if defined(MOZ_ENABLE_DBUS)
  if (!useX11Remote || getenv(DBUS_REMOTE_ENV)) {
    mRemoteServer = MakeUnique<nsDBusRemoteServer>();
  }
#  endif
  if (!mRemoteServer && useX11Remote) {
    mRemoteServer = MakeUnique<nsGTKRemoteServer>();
  }
#elif defined(XP_WIN)
  mRemoteServer = MakeUnique<nsWinRemoteServer>();
#elif defined(XP_DARWIN)
  mRemoteServer = MakeUnique<nsMacRemoteServer>();
#else
  return;
#endif

  nsresult rv = mRemoteServer->Startup(mProgram.get(), mProfile.get()); <=====

  if (NS_FAILED(rv)) {
    mRemoteServer = nullptr;
    return;
  }

  nsCOMPtr<nsIObserverService> obs(
      do_GetService("@mozilla.org/observer-service;1"));
  if (obs) {
    obs->AddObserver(this, "xpcom-shutdown", false);
    obs->AddObserver(this, "quit-application", false);
  }
}

[Comment 6 Michael Hofmann 2020-12-28 16:02:37 UTC]

I re-emerged Firefox with USE flag 'dbus'. Firefox works now in Wayland mode. :-)

Could it be that USE flag 'wayland' requires USE flag 'dbus'?

[Comment 7 Michael Hofmann 2020-12-28 16:28:58 UTC]

I created a bug at Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1684365

It's not about the Wayland problem itself. It's about a missing error check that leads to the SIGSEGV.

[Comment 8 fee1-dead-beef 2020-12-29 09:11:10 UTC]

Hi, this is probably because firefox will try to use DBus to enable the remote control feature, from the wiki: https://wiki.gentoo.org/wiki/Firefox#gtk.2B:3_pulls_in_DBUS. You should try running with MOZ_NO_REMOTE set or with the --no-remote argument.

[Comment 9 sklv_gentoo 2020-12-29 18:18:50 UTC]

Can confirm that when built with -dbus, and launching with --no-remote, the segfault does not happen.

[Comment 10 Aaron Stein 2021-01-16 05:18:51 UTC]

I can confirm this segfault with same backtrace on 84.0.2 and 78.6.1 when firefox is emerged with +wayland and -dbus. The segfault does not happen when launching with --no-remote, or when built with USE=dbus.

[Comment 11 Joonas Niilola 2021-01-16 06:38:00 UTC]

Thanks for all the investigative work. I see a couple of ways to "solve" this, 

1: Add REQUIRED_USE for wayland? ( dbus ).

2: Print a warning after package is installed if "+wayland -dbus" USE combination is detected, that user must launch firefox with "--no-remote".

3: Via ebuild add "--no-remote" to firefox-wayland.desktop when the USE flag combination is detected.

4: Wait until the upstream patch gets reviewed, and ship that.
  https://phabricator.services.mozilla.com/D101536
  https://d3kxowhw4s8amj.cloudfront.net/file/data/lo2bev75storfxldgfm7/PHID-FILE-hg6z6my3l6qkcwyi3qsm/D101536.diff

[Comment 12 Larry the Git Cow 2021-02-01 15:01:12 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b09aec4cfcea54e707c10926ade02667a60e710f

commit b09aec4cfcea54e707c10926ade02667a60e710f
Author:     Thomas Deutschmann <[e-mail]>
AuthorDate: 2021-02-01 14:36:42 +0000
Commit:     Thomas Deutschmann <[e-mail]>
CommitDate: 2021-02-01 15:01:00 +0000

    www-client/firefox: rev bump for updated patch set
    
    Closes: https://bugs.gentoo.org/762035
    Package-Manager: Portage-3.0.14, Repoman-3.0.2
    Signed-off-by: Thomas Deutschmann <[e-mail]>

 www-client/firefox/Manifest               |    1 +
 www-client/firefox/firefox-85.0-r1.ebuild | 1120 +++++++++++++++++++++++++++++
 2 files changed, 1121 insertions(+)

[Comment 13 Michael Hofmann 2021-02-01 15:57:10 UTC]

Wait... The bug was fixed by upstream (my patch was accepted). But only for Firefox 87. The bug is still present in Firefox 78, 84 and 85 and it will probably be present in Firefox 86.

[Comment 14 Thomas Deutschmann (RETIRED) 2021-02-01 17:38:38 UTC]

It's now included in our patch set. ESR bump is pending.

[Comment 15 Michael Hofmann 2021-02-01 20:13:17 UTC]

Ah, I see! Thanks!

I just emerged Firefox 85.0-r1. The patch is included and it works! :-)