Can't use --profile - dbus assertion failure

UNCONFIRMED
Unassigned

Status

()

Toolkit
Startup and Profile System
UNCONFIRMED
16 days ago
15 days ago

People

(Reporter: yan12125, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 days ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180101220336

Steps to reproduce:

Run Firefox with a custom profile path:

mkdir /tmp/firefox_profile
firefox-nightly --profile /tmp/firefox_profile


Actual results:

dbus[7907]: arguments to dbus_bus_request_name() were incorrect, assertion "_dbus_check_is_valid_bus_name (name)" failed in file dbus-bus.c line 1122.
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 7996
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...



Expected results:

Firefox runs fine in a new and clean profile
(Reporter)

Comment 1

16 days ago
Further investigation:

If I set a breakpoing at dbus_bus_request_name and dump the second argument, it looks broken:

(gdb) p (char*)$rsi
$4 = 0x7fffcc1ec2cc "org.mozilla.firefox."
AFAIK, you should not pass the path to a profile directory as an argument to the --profile command. But rather create a profile in the profile manager and use the name of this profile as an argument

https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
https://support.mozilla.org/en-US/kb/using-dedicated-profile-firefox-nightly
(Reporter)

Comment 3

15 days ago
Thanks for the info. The profile manager approach works fine. I remember --profile also worked fine for some previous version, and it's simpler for quick testing against a clean profile.

A workaround is adding -no-remote along with --profile.
Well, -P or --profile both work fine. And -no-remote works for both IIRC.
Is your issue fixed? Are you able to use command line to launch the new profile created with the profile manager?
(Reporter)

Comment 5

15 days ago
> Are you able to use command line to launch the new profile created with the profile manager?

-P works and -no-remote --profile work. --profile without -no-remote not.

$ firefox-nightly --new-instance --profile ~/.mozilla/firefox/ikfmrr88.foobar
dbus[30815]: arguments to dbus_bus_request_name() were incorrect, assertion "_dbus_check_is_valid_bus_name (name)" failed in file dbus-bus.c line 1122.
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 30879
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...

$ firefox-nightly --new-instance -P foobar                                   

$ firefox-nightly --new-instance --profile ~/.mozilla/firefox/ikfmrr88.foobar -no-remote

$
When you launch nightly with this new profile, is there another instance of Firefox (Release, Beta, Nightly... whatever) open?
This would explain the errors and why it works only with the -no-remote argument.

You can't normally launch 2 instances of Firefox (whatever the channel) at the same time (even with 2 different profiles). You can do that only by using -no-remote (and still with 2 different profiles)
(Reporter)

Comment 7

15 days ago
Yep there was another instance the last time I tested it. I close other Firefox processes and test again . Here are the results:

$ firefox-nightly --profile ~/.mozilla/firefox/ikfmrr88.foobar -no-remote        

$ firefox-nightly --profile ~/.mozilla/firefox/ikfmrr88.foobar           
dbus[28392]: arguments to dbus_bus_request_name() were incorrect, assertion "_dbus_check_is_valid_bus_name (name)" failed in file dbus-bus.c line 1122.
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 28454
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...

$ firefox-nightly -P foobar                                   

Sorry for confusion.
Component: Untriaged → Startup and Profile System
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.