Closed Bug 1661274 Opened 4 years ago Closed 4 years ago

widget/gtk/ProcInfo.cpp:249:55: error: too many arguments to function call, expected 0, have 1

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Platform:
Unspecified
FreeBSD
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
82 Branch
Tracking Flags:
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox79 --- unaffected
firefox80 --- unaffected
firefox81 --- fixed
firefox82 --- fixed

People

(Reporter: jbeich, Assigned: Yoric)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

example fix
1.37 KB, patch
Yoric
: review+
gaston
: feedback+
gaston
: feedback+
Details | Diff | Splinter Review
Bug 1661274 - Unbreak Gtk build on non-Linux after bug 1652813;r?froydnj
47 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
Details | Review

ProcInfo and ResidentUnique reporter are not implemented on Tier3 platforms (e.g., 4 BSDs, Solaris). ProcInfo built fine before bug 1652813 but didn't work as well. Downstream no one complained about always empty about:processes.

$ c++ --version
FreeBSD clang version 11.0.0 (git@github.com:llvm/llvm-project.git llvmorg-11.0.0-rc2-0-g414f32a9e86)
Target: x86_64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin

$ ./mach bootstrap
$ ./mach build
[...]
In file included from Unified_cpp_widget_gtk0.cpp:101:
widget/gtk/ProcInfo.cpp:249:55: error: too many arguments to function call, expected 0, have 1
              nsMemoryReporterManager::ResidentUnique(request.pid);
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~
objdir/dist/include/nsMemoryReporterManager.h:188:3: note: 'ResidentUnique' declared here
  static int64_t ResidentUnique();
  ^
In file included from Unified_cpp_xpcom_base2.cpp:29:
xpcom/base/nsMemoryReporterManager.cpp:2415:34: error: out-of-line definition of 'ResidentUnique' does not match any declaration in 'nsMemoryReporterManager'
int64_t nsMemoryReporterManager::ResidentUnique(ResidentUniqueArg) {
                                 ^~~~~~~~~~~~~~

Can you help landing the fix or propose an alternative?

status-firefox79: --- → unaffected
status-firefox80: --- → unaffected
status-firefox81: --- → affected
status-firefox-esr68: --- → unaffected
status-firefox-esr78: --- → unaffected
Flags: needinfo?(dteller)
Comment on attachment 9172205 [details] [diff] [review]
example fix

Review of attachment 9172205 [details] [diff] [review]:
-----------------------------------------------------------------

Yep, that would work!
Thanks for the patch!
Attachment #9172205 - Flags: review+
Flags: needinfo?(dteller)

Comment on attachment 9172205 [details] [diff] [review]
example fix

Faced the same issue on OpenBSD, this patch (among others) allowed me to build 81.0b2.

Yoric, can you land this for jbeich ? Many thanks !

Flags: needinfo?(dteller)
Attachment #9172205 - Flags: feedback+

Comment on attachment 9172205 [details] [diff] [review]
example fix

Faced the same issue on OpenBSD, this patch (among others) allowed me to build 81.0b2.

Yoric, can you land this for jbeich ? Many thanks !

Attachment #9172205 - Flags: feedback+

(In reply to Jan Beich from comment #4)

(In reply to Darkspirit, Servo QA from comment #3)

Please don't use one password for every website, it's highly problematic. With Firefox' built-in password manager you can create a unique password per website.

I'm fine with multiple passwords but I don't trust Mozilla enough to discard GitHub 2FA. Unfortunately, using both 2FA providers together is not possible.

It's Mozilla who needs to trust your Bugzilla session, "you don't need to trust Mozilla". With so many people laid off I wouldn't even assume someone had the time to revise this topic, to make the implementation more complex. You can still use Github on other Mozilla logins. This doesn't affect your Firefox Account or Mozilla IAM.
Are you able to set a password on https://bugzilla.mozilla.org/userprefs.cgi to switch from Github auth to Bugzilla auth?
Then you can log in to Phabricator. Also see Mozilla Phabricator User Guide. Thank you :)

(In reply to Darkspirit, Servo QA from comment #8)

It's Mozilla who needs to trust your Bugzilla session, "you don't need to trust Mozilla".

GitHub can require everyone in an organization to have 2FA enabled, show 2FA status of an organization member or any random user using their API key for read:user (Read all user profile data) permission.

$ curl -H "Authorization: token <REDACTED>" https://api.github.com/users/jbeich |
  jq '.two_factor_authentication'
true

You can still use Github on other Mozilla logins.

According to Preferences -> Two-Factor Authentication: "As part of this transition you will no longer be able to use GitHub to log in to Bugzilla."

Are you able to set a password on https://bugzilla.mozilla.org/userprefs.cgi to switch from Github auth to Bugzilla auth?

I don't want to switch "from" existing 2FA. If a password is necessary it should be on top of GitHub login, not instead.
Ironically, Mozilla spells 2FA as MFA in Phabricator except the said MFA doesn't support 3FA.

(In reply to Jan Beich from comment #9)

According to Preferences -> Two-Factor Authentication: "As part of this transition you will no longer be able to use GitHub to log in to Bugzilla."

Please do that. <3 You especially mentioned bug 1536716 in comment 1 (and many bugs before), but an own Bugzilla password and 2FA is unfortunaly required to get patches merged conveniently. It's even more unrealistic bug 1536716 could be implemented as 250 people have been fired, 25% of Mozilla. :/ In 1 minute you could configure a Bugzilla password and 2FA, saving yours and others valuable time to get a patch merged. Please, it's such a small task compared to an infrastructural change for one person by a such decimated workforce. You will like moz-phab. :)

Assignee: nobody → dteller
Status: NEW → ASSIGNED
Pushed by dteller@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/827801d6b7eb
Unbreak Gtk build on non-Linux after bug 1652813;r=froydnj
Flags: needinfo?(dteller)

https://hg.mozilla.org/mozilla-central/rev/827801d6b7eb

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox82: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch

The patch landed in nightly and beta is affected.
:Yoric, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(dteller)

What do you think, Jan? (see comment 14)

Flags: needinfo?(dteller) → needinfo?(jbeich)

Comment on attachment 9172595 [details]
Bug 1661274 - Unbreak Gtk build on non-Linux after bug 1652813;r?froydnj

Beta/Release Uplift Approval Request

  • User impact if declined: FTBFS on non-linux
  • Is this code covered by automated tests?: Unknown
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): NPOTB
  • String changes made/needed: none
Attachment #9172595 - Flags: approval-mozilla-beta?

will be welcome in 81.0b4 or b5, thanks !

Comment on attachment 9172595 [details]
Bug 1661274 - Unbreak Gtk build on non-Linux after bug 1652813;r?froydnj

Approved for 81.0b5.

Flags: needinfo?(jbeich)
Attachment #9172595 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: