1274846 - Linux: restart to update doesn't work when using two firefox processes (different profiles) simultaneously

Status: NEW

(Toolkit :: Startup and Profile System, defect)

Description

[Will Levine]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160522030240

Steps to reproduce:

Start two Firefox processes using different profiles:

./firefox -P profile1 --new-instance &
./firefox -P profile2 --new-instance &

At some point, Firefox downloads an updated version and wants you to restart to update. First you restart the first process, then you click the "restart to update" button in the second process.


Actual results:

The second firefox process does not restart and has to be re-run manually. Firefox exits with an error and the next time you open it, the tab restore "This is embarrassing" page comes up. This is the error when firefox shuts down:

(process:29823): GLib-CRITICAL **: g_path_get_basename: assertion 'file_name != NULL' failed
sh: 0: getcwd() failed: No such file or directory
sh: 0: getcwd() failed: No such file or directory

[1]-  Exit 1                  ./firefox -P will_browsing_new --new-instance


Expected results:

The second Firefox process restarts normally.

Comment 1

[Abe - QA (:Abe_LV)]

Yes, the second Firefox does not restart automatically when "Restart Nightly to apply updates" is clicked. It has to be restarted manually. However; when it launched manually/command line/, I am not seeing errors.

---Nightly Version before Update---
Version 	49.0a1
Build ID 	20160501030217
Update Channel 	nightly
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0

Comment 2

[Benjamin Smedberg]

Interesting: I suspect that when we apply the update, the running Firefox ends up in a directory which is no longer mounted, so it doesn't have a path. It would be really helpful to have a stacktrace from the assertion. Could you help catch that?

Comment 3

[Will Levine]

I think that's right: when I go back to the terminal that I originally launched firefox from and do an ls, the directory appears to be empty (or non-existent?), but then if I do `cd ../firefox`, I end up in the new directory with the updated firefox.

How do I get a stacktrace? I don't have a debug build or anything.

Comment 4

[Benjamin Smedberg]

Hrm, that's a good question. I don't think we have downloadable symbol packages for our Linux builds, so attaching with gdb would produce mostly garbage by default. Ted, I know that we've used tools to translate between cores and minidumps... do you have instructions for how somebody might do this? I presume breakpad isn't useful in this case because the crash happens either early in startup or late in shutdown.

Comment 5

[(not currently active) Ted Mielczarek]

If you have a new-enough GDB (7.9 or newer) I have a GDB Python script that will fetch symbols from the symbol server:
https://developer.mozilla.org/en-US/docs/Mozilla/Using_the_Mozilla_symbol_server#Downloading_symbols_on_Linux_Mac_OS_X

If not, there's a link there to a fetch-symbols.py script you can use to download symbols for use with GDB.

Comment 6

[Herman van Rink]

I've also noticed that when you click the restart button after an update while multiple profiles are running no new FF is started.

Could this be as simple as a 'is it already running' check that is not taking the profile into account?

using: Firefox 67 on Ubuntu 18.04.

Comment 7

[Saïmonn]

Reproduced this bug while updating to Nightly 74 on Debian Buster:

1. start Firefox with Default Profile. Use it a bit.
2. start Firefox with Profile2. It displays "You’ve just been upgraded to Firefox Nightly 74!"
3. Click the restart button on Firefox Default Profile.
4. Firefox Default Profile exits, but doesn't restart. Profile2 session is left untouched.

Firefox Default profile was launched with nohup command, here is the content of nohup.out:

[Parent 2846, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 23
[Parent 2846, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 23
[Parent 2846, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 23
[Parent 2846, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 23
[Parent 2846, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 23
[Parent 2846, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 23

###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost