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

Steps to reproduce:

OS: Fedora 33/34
Version: 94.0

I tried "killall firefox" and it did not find any processes while Firefox was running.

Actual results:

nothing.. process was not found, because the processes are named "GeckoMain".

Expected results:

the process should be named "firefox"

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Cannot reproduce on Fedora 35. How did you install Firefox? Have you first reported this to Fedora, and did they say this is an upstream issue?

yes and no. It's been reported to Fedora here:

https://bugzilla.redhat.com/show_bug.cgi?id=2018593

But not to the firefox component, as this has already happend last year and got fixed in "psmisc" :

https://bugzilla.redhat.com/show_bug.cgi?id=1869413

We can add the firefox maintainer in the process if you think it's a downstream issue.

Yes, it's really named 'GeckoMain'. You need to gnome-system-monitor or similar tool.

Can this be derived from first thread name?
https://searchfox.org/mozilla-central/rev/ac7a567f036e1954542763f4722fbfce041fb752/mozglue/baseprofiler/core/platform.cpp#1206

I bisected this, looking for the revision that introduced the "GeckoMain" rename.

Last good revision: 4a5ea1a36729d14cc7a79db631dbf101c6a69465
First bad revision: 12796ed8484e8fd56b5c87d7a11fb0dda3f01492
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4a5ea1a36729d14cc7a79db631dbf101c6a69465&tochange=12796ed8484e8fd56b5c87d7a11fb0dda3f01492

Regressed by bug 1722261.

Good detective work, thank you.

That code was supposed to do the same thing as before, but changing the data structures to more safe ones behind the Profiler scenes.

A quick test shows that removing the NS_SetCurrentThreadName in ThreadRgistry::Register() fixes the issue!

I see now that profiler_init() used to call locked_register_thread("GeckoMain"), bypassing the NS_SetCurrentThreadName() in the public profiler_register_thread() function!

I would argue that NS_SetCurrentThreadName should change the thread name and not the process name, as the function name advertises! Is it a Linux thing, that the main thread name controls the process name? (I know they have the same pid and tid.)

Anyway, I should probably change this back to how it worked before, and avoid changing the main thread name.

It is indeed a "Linux thing" that the main thread's name is the process' name.

The name of the main thread outside the profiler should not be set by the profiler (to "GeckoMain"), as this main affect the name of the application itself on some systems like Linux.

Added tests to ensure that the profiler doesn't set that main thread public name to "GeckoMain", and also that other threads are publicly named when first registered with the profiler.

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

https://hg.mozilla.org/mozilla-central/rev/3b6dfbfb17fb