1427579 - Can't use --profile - dbus assertion failure

Status: RESOLVED DUPLICATE of bug 1429021

(Toolkit :: Startup and Profile System, defect)

Description

[Chih-Hsuan Yen [:yan12125] (UTC+8)]

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

Comment 1

[Chih-Hsuan Yen [:yan12125] (UTC+8)]

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."

Comment 2

[Flore Allemandou [:flore]]

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

Comment 3

[Chih-Hsuan Yen [:yan12125] (UTC+8)]

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.

Comment 4

[Flore Allemandou [:flore]]

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?

Comment 5

[Chih-Hsuan Yen [:yan12125] (UTC+8)]

> 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

$

Comment 6

[Flore Allemandou [:flore]]

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)

Comment 7

[Chih-Hsuan Yen [:yan12125] (UTC+8)]

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.

Comment 8

[Mikhail E Krasilnikiov]

I have the same problem with Firefox 59.0.1.

~> /usr/bin/firefox -P Разработка
dbus[5787]: 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 5855
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...

Failed to open curl lib from binary, use libcurl.so instead

—————————————————————————

~> /usr/bin/firefox
dbus[5883]: 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 5982
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child

Failed to open curl lib from binary, use libcurl.so instead

—————————————————————————

~> /usr/bin/firefox -ProfileManager
dbus[6043]: 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 6143
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child

Failed to open curl lib from binary, use libcurl.so instead

—————————————————————————

And only this works:

~> /usr/bin/firefox -ProfileManager -no-remote