Closed Bug 1551664 Opened 5 years ago Closed 4 years ago

[Wayland] Developer Edition crashes on startup, nightly working fine

Categories

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

67 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla74
Tracking Status
firefox74 --- fixed

People

(Reporter: zach, Assigned: stransky)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

Tested the latest binary firefox-beta release provided on Mozilla's site (67.0) with Wayland using GDK_BACKEND=wayland ./firefox
Firefox starts up and appears to work as expected.

Tested with the latest binary firefox-developer-edition provided on Mozilla's site (

Actual results:

firefox-developer-edition immediately crashes.

GDK_BACKEND=wayland ./firefox
dbus[8087]: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1366.
This is normally a bug in some application using the D-Bus library.

  D-Bus not built with -rdynamic so unable to print a backtrace
Redirecting call to abort() to mozalloc_abort

ExceptionHandler::GenerateDump cloned child 8101
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...

Crash Report info:

BuildID: 20190513111358
CrashTime: 1557859672
InstallTime: 1557858813
MozCrashReason: MOZ_CRASH()
ProductID: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
ProductName: Firefox
ReleaseChannel: aurora
SafeMode: 0
SecondsSinceLastCrash: 47
StartupCrash: 1
StartupTime: 1557859672
ThreadIdNameMapping: 
Throttleable: 1
UptimeTS: .11449708
Vendor: Mozilla
Version: 68.0

This report also contains technical information about the state of the application when it crashed.

System Info:

Linux 5.0.13-arch1-1-ARCH #1 SMP PREEMPT Sun May 5 18:05:41 UTC 2019 x86_64 GNU/Linux
gnome-desktop 3.32.2-1
D-Bus Message Bus Daemon 1.12.12

Expected results:

When testing the latest binary firefox-beta release provided on Mozilla's site (67.0) with Wayland using GDK_BACKEND=wayland ./firefox
Firefox starts up and appears to work as expected.

Firefox Nightly (68.0a1 2019-05-14 64-bit) starts up and appears to work as expected with wayland support as well.

This is what I would expect firefox-developer-edition to do.
Not sure if firefox-developer-edition just isn't compiled with it or if the issue is elsewhere. Happy to provide additional info and testing

Summary: [Wayland] Developer Edition crashes on startup, beta working fine → [Wayland] Developer Edition crashes on startup, nightly working fine
Component: Untriaged → Widget: Gtk
Product: Firefox → Core

I expect it's related to default dev edition profile name which is different than the Nightly one.

Blocks: wayland
Priority: -- → P2

This is triggered by the dev-edition setting MOZ_APP_REMOTINGNAME=firefox-dev. This remoting name is inserted into various strings in nsDBusRemoteServer/Client.

The problem is that dashes are not valid in D-Bus object paths (hence the assert in _dbus_check_is_valid_path). The code could sanitize the produced object path to ensure it is valid, but I would suggest just picking a static /org/mozilla/firefox since the unique bus name is enough to ensure we don't get any conflicts.

The same goes for the interface name, which also does not allow dashes and should be a static org.mozilla.firefox.

The bus name needs to be unique to each install. It should be sanitized to ensure it always works. It's not a problem for firefox-dev, but someone could get the idea of using something like 1-my-firefox@apps.1domain.example as the remoting name: @ is invalid; . is valid but problematic as it's the element separator; - is discouraged; starting an element with a digit is invalid.

Because my libdbus is built with less checking/asserts, I don't get a crash on startup but the remoting does not work.

Assignee: nobody → stransky
Attachment #9120747 - Attachment description: Bug 1551664 [Wayland] Validate app name and check dbus patch, r?heftig → Bug 1551664 [Wayland] Validate app name and check dbus path for remote server, r?heftig

Remote client also needs this update, patch added, Thanks.

Status: UNCONFIRMED → NEW
Ever confirmed: true

(In reply to Jan Alexander Steffens [:heftig] from comment #2)

This is triggered by the dev-edition setting MOZ_APP_REMOTINGNAME=firefox-dev. This remoting name is inserted into various strings in nsDBusRemoteServer/Client.

The bus name needs to be unique to each install. It should be sanitized to ensure it always works. It's not a problem for firefox-dev, but someone could get the idea of using something like 1-my-firefox@apps.1domain.example as the remoting name: @ is invalid; . is valid but problematic as it's the element separator; - is discouraged; starting an element with a digit is invalid.

I'd rather keep the app name here as the same code is used for thunderbird for instance.

Pushed by btara@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b58ad41837a6
[Wayland] Validate app name and check dbus path for remote server, r=heftig
https://hg.mozilla.org/integration/autoland/rev/4222f7b9c86b
[Wayland] Validate app name and check dbus path for remote client, r=heftig
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla74
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: