1465895 - Default to mach-installed clang directory for sanitizer tools

Status: RESOLVED FIXED

(Core :: JavaScript Engine, enhancement, P3)

Description

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

The sanitizer builds use TOOLTOOL_CHECKOUT to find the llvm-symbolizer binary. For local builds, that won't work.

Comment 1

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

Attachment: Default to mach-installed clang directory for sanitizer tools

But for local builds, we will probably have clang installed in ~/.mozbuild (that's the default for mach bootstrap), so fall back to that instead of the directory I personally happened to copy things to.

nbp: Thanks for volunteering to take testing-related patch reviews! My apologies in advance for all the random bits and pieces I'll be sending your way. Ordinarily, my default reviewer is jonco, but I send him too much stuff already and most of this should be pretty minor from a reviewing perspective. I hope.

Comment 2

[Nicolas B. Pierron [:nbp]]

Comment on attachment 8982297 [details] [diff] [review]
Default to mach-installed clang directory for sanitizer tools

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

::: js/src/devtools/automation/autospider.py
@@ +23,5 @@
>      scripts = pathmodule.join(fixup(cwd), fixup(pathmodule.dirname(__file__)))
>      js_src = pathmodule.abspath(pathmodule.join(scripts, "..", ".."))
>      source = pathmodule.abspath(pathmodule.join(js_src, "..", ".."))
>      tooltool = pathmodule.abspath(env.get('TOOLTOOL_CHECKOUT',
> +                                          pathmodule.expanduser("~/.mozbuild")))

nit: Use the following default value:
  env.get('MOZBUILD_STATE_PATH', pathmodule.expanduser(pathmodule.join('~', '.mozbuild')))

Taken from toolkit/moz.configure

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/30c5d06e47f0
Default to mach-installed clang directory for sanitizer tools, r=nbp

Comment 4

[Cristian Brindusan [:cbrindusan]]

Backed out changeset 30c5d06e47f0 (bug 1465895) for spidermonkey bustages. 

Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/a6d7c670b2f564c8c1c0fee8652dde0ec308ab10

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=30c5d06e47f09e78e399f1d93878af63aad2deea&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=success&filter-resultStatus=pending&filter-resultStatus=running&selectedJob=181284024

Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=181284024&repo=mozilla-inbound&lineNumber=739

Traceback (most recent call last):
  File "./src/js/src/devtools/automation/autospider.py", line 37, in <module>
    fixup=lambda s: re.sub(r'^(\w):', r'/\1', s))
  File "./src/js/src/devtools/automation/autospider.py", line 29, in directories
    pathmodule.expanduser("~/.mozbuild"))))
  File "c:\mozilla-build\python\lib\posixpath.py", line 261, in expanduser
    import pwd
ImportError: No module named pwd

Comment 5

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

This is... harder to land than anticipated.

First, the 'pwd' module is mysteriously missing, as you can see in comment 4.

So I had it fall back to os.environ['HOME']. Which now claims (on try) that $HOME doesn't exist??!

Hm -- come to think of it, why did it get that far? In automation, TOOLTOOL_CHECKOUT should be set.

Comment 6

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

Oh. These failures are all on Windows. I guess that makes more sense.

Though I'm still not sure why mozilla-build's python would have posixpath but not pwd.

Comment 7

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

oh, duh. "pwd" != "print working directory". pwd is PassWord Database. :(

Comment 8

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

I'm pretty sure this code has been rewritten.