Since bug 1646803, firefox shows up as "MainThread" when using the top util on Linux.

It looks like other processes call SetThisProcessName.

In top I see other Firefox processes being called "WebExtensions" or "Privileged Cont". That doesn't seem great either.

If we wanted to be consistent with the other processes, we could set the parent process name to "Parent Process", but that wouldn't help much in top. Maybe https://searchfox.org/mozilla-central/rev/5a4aaccb28665807a6fd49cf48367d47fbb5a19a/ipc/glue/ProcessUtils_linux.cpp#17 needs to add a Firefox prefix?

I think we should just continue calling it firefox and revert this change completely. If you want to kill a misbehaving firefox instance that is what you look for in ps. IInstead of changing the process name we could instead special case the parent-process in about:processes.

(In reply to Tom Schuster [:evilpie] from comment #2)

I think we should just continue calling it firefox and revert this change completely. If you want to kill a misbehaving firefox instance that is what you look for in ps.

ps still shows firefox-bin.

IInstead of changing the process name we could instead special case the parent-process in about:processes.

I'm not sure what that means. Bug 1646803 changes the thread name, because about:processes can't guess which thread is what without the thread having a name. The process name gets changed as a side effect because the process doesn't have a name yet.

(In reply to Florian Quèze [:florian] from comment #3)

(In reply to Tom Schuster [:evilpie] from comment #2)

I think we should just continue calling it firefox and revert this change completely. If you want to kill a misbehaving firefox instance that is what you look for in ps.

ps still shows firefox-bin.

Not for me. Linux Mint 19.3

>ps -e | grep MainThread
2417 ?        00:43:37 MainThread

IInstead of changing the process name we could instead special case the parent-process in about:processes.

I'm not sure what that means. Bug 1646803 changes the thread name, because about:processes can't guess which thread is what without the thread having a name. The process name gets changed as a side effect because the process doesn't have a name yet.

Isn't the main thread special? From my understanding the thread id of the main thread is the same as the process id, so this should be easy to manually overwrite.

But I get what you are saying now. Maybe we should give the firefox process an explicit name.

(In reply to Tom Schuster [:evilpie] from comment #4)

From my understanding the thread id of the main thread is the same as the process id, so this should be easy to manually overwrite.

I tested a bit and indeed on Linux the thread id of the main thread is the same as the process id. This is not the case on OS X or Windows.

I also noticed when testing about:processes on Linux that for the other processes, we don't have a "MainThread" thread listed, and instead we show the process name. So it's quite possible that on Linux we can't give a separate name to the process and the main thread.

So... maybe we need to ifdef out the patch from bug 1646803 on linux, and special case Linux in about:proesses to show "MainThread" for any thread with a thread id matching the process id. Yoric, what do you think of this?

Yet another thing I noticed: when looking at about:processes on Linux, I don't see any "???" thread (on OS X and Windows we have a few threads that don't have a name). I wonder if somehow the API we are using on Linux to get the list of threads could be skipping the nameless threads.

Set release status flags based on info from the regressing bug 1646803

(In reply to Florian Quèze [:florian] from comment #5)

(In reply to Tom Schuster [:evilpie] from comment #4)
So it's quite possible that on Linux we can't give a separate name to the process and the main thread.

I'll try and test this as soon as I've solved my current computer issues.

So... maybe we need to ifdef out the patch from bug 1646803 on linux, and special case Linux in about:proesses to show "MainThread" for any thread with a thread id matching the process id. Yoric, what do you think of this?

I don't think we're supposed to rely upon the value of the process id. So, not a big fan at this stage.

Yet another thing I noticed: when looking at about:processes on Linux, I don't see any "???" thread (on OS X and Windows we have a few threads that don't have a name). I wonder if somehow the API we are using on Linux to get the list of threads could be skipping the nameless threads.

That would be surprising but it could be a bug in the implementation. I'll check this out.

(In reply to David Teller [:Yoric] (please use "needinfo") from comment #7)

(In reply to Florian Quèze [:florian] from comment #5)

(In reply to Tom Schuster [:evilpie] from comment #4)
So it's quite possible that on Linux we can't give a separate name to the process and the main thread.

Yeah, I feel that this is the case.

So... maybe we need to ifdef out the patch from bug 1646803 on linux, and special case Linux in about:proesses to show "MainThread" for any thread with a thread id matching the process id. Yoric, what do you think of this?

Can't find a better idea for the moment :(

Yet another thing I noticed: when looking at about:processes on Linux, I don't see any "???" thread (on OS X and Windows we have a few threads that don't have a name). I wonder if somehow the API we are using on Linux to get the list of threads could be skipping the nameless threads.

I've done some testing. As far as I can tell, under Linux, all threads have a name. Maybe it's gtk giving some threads a name automatically?

FWIW (maybe not much, but that'll supposedly be decided by the fate of the procps report, also reported at https://gitlab.com/procps-ng/procps/-/issues/180

(In reply to David Teller [:Yoric] (please use "needinfo") from comment #8)

Yet another thing I noticed: when looking at about:processes on Linux, I don't see any "???" thread (on OS X and Windows we have a few threads that don't have a name). I wonder if somehow the API we are using on Linux to get the list of threads could be skipping the nameless threads.

I've done some testing. As far as I can tell, under Linux, all threads have a name. Maybe it's gtk giving some threads a name automatically?

Threads are created inheriting the name of the thread that spawned them. Some libraries rename them afterwards.

*/1 * * * * cpulimit -p $(pgrep MainThread) -l 50

Now that about:processes doesn't even show threads anymore can we revert this change, at least on Linux?

(In reply to Tom Schuster [:evilpie] from comment #13)

Now that about:processes doesn't even show threads anymore can we revert this change, at least on Linux?

It still shows threads, but that's on the way out. So I have no objection.

(In reply to Tom Schuster [:evilpie] from comment #13)

can we revert this change, at least on Linux?

I agree that on Linux the change from bug 1646803 doesn't help, but it works fine on Mac, and I think on Windows too, so I would prefer that we revert only on Linux, with an ifdef.

This is unrelated to this bug. You can open a new bug for main process memory usage.

https://hg.mozilla.org/mozilla-central/rev/e92f5272e134

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

This bug persists in Firefox 93.0 and it is very confusing that you start a browser with firefox but to kill it you need to killall MainThread.
The name MainThread is also more likely to not be unique on a system and is a poor choice for a process name in my opinion.

I wasn't sure if I should create a new bug or comment on this one, there were no option for "bug is closed but persists".