1705783 - Consider using MOZ_AUTOMATION for SM(pkg)

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P3)

Description

[Steve Fink [:sfink] [:s:]]

https://phabricator.services.mozilla.com/D109164?id=427994#inline-625484

Comment 1

[Steve Fink [:sfink] [:s:]]

Heh. The first failure is pointedly relevant:

[task 2021-04-16T17:50:09.377Z]  0:00.84 ERROR: unable to resolve VCS type; must run from a source checkout when MOZ_AUTOMATION is set

Comment 2

[Steve Fink [:sfink] [:s:]]

Attachment: Bug 1705783 - Allow --enable-project=mozjs to build the 'js' project with defaults for the standalone spidermonkey source package

Comment 3

[Steve Fink [:sfink] [:s:]]

Attachment: Bug 1705783 - Re-order some configuration to enable later change.

Comment 4

[Steve Fink [:sfink] [:s:]]

Attachment: Bug 1705783 - Default --enable-project to 'mozjs' if sentinel file README-mozjs is found.

Comment 5

[Steve Fink [:sfink] [:s:]]

Attachment: Bug 1705783 - add configure option --js-package and stop clearing MOZ_AUTOMATION for SM(pkg)

Comment 6

[Steve Fink [:sfink] [:s:]]

I'm not a fan of having --enable-project take something that is not a directory containing a moz.configure file just to work around one check in configure (AFAICT) about VCS and MOZ_AUTOMATION. I'd rather allow to override just that.

Ok. To be clear, it would control both the VCS detection as well as the default for --enable-jemalloc. And I guess I have a preference for it to be done automatically when you're configuring the mozjs source tree.

Before I write the patch (for once), let me check: would you be ok with me adding a --js-package flag that

• is defaulted based on the presence of a README-mozjs file
• skips the VCS check
• sets --disable-jemalloc by default
  ?

The goal is to make ./mach build within a mozjs source package do something roughly reasonable.

I finally know my way around moz.configure enough now that it won't be hard to implement whatever is acceptable.

Comment 7

[Mike Hommey [:glandium]]

Can you remind me why local builds of js need jemalloc enabled by default?

Comment 8

[Steve Fink [:sfink] [:s:]]

(In reply to Mike Hommey [:glandium] from comment #7)

Can you remind me why local builds of js need jemalloc enabled by default?

Because they are proxies for testing the JS engine as it would be embedded in the browser, and that would have jemalloc enabled. Not only the exact allocation behavior is affected, but also we make use of some differences in the available API surface -- jemalloc_ptr_info and malloc_good_size, for example. The first is for debug assertions, the second changes behavior. We want to maximize the probability that issues that exist in the browser will also exist in the shell builds.

Comment 9

[Mike Hommey [:glandium]]

My bet is that /something/ installed on the machine and used to execute the test at some level of the process hierarchy, is a x64 binary. First guess: /usr/local/bin/python2 (why are we even installing an extra python2, when macos comes with one?).

Comment 10

[Mike Hommey [:glandium]]

Yeah, both /usr/local/bin/python3 and /usr/local/bin/python2 (both used to launch the test) are x64: https://firefoxci.taskcluster-artifacts.net/DwXClaQVQZyBHoNwnLArVw/0/public/logs/live_backing.log

Comment 11

[Mike Hommey [:glandium]]

Huh, it's even worse than that... the worker process seems to be using a x64 binary, per the beginning of the log about the worker type.

Comment 12

[Mike Hommey [:glandium]]

In fact, most things in /usr/local are x64 binaries https://firefoxci.taskcluster-artifacts.net/Phl3tFj0RE6wbIGb1RsjCw/0/public/logs/live_backing.log

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/15f0e4e860b5
add configure option --js-package and stop clearing MOZ_AUTOMATION for SM(pkg) r=glandium,firefox-build-system-reviewers

Comment 14

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/15f0e4e860b5