Use Clang Trunk for ASan builds

RESOLVED FIXED in Firefox 59

Status

enhancement
--
major
RESOLVED FIXED
2 years ago
Last year

People

(Reporter: decoder, Assigned: decoder)

Tracking

(Blocks 1 bug)

Trunk
mozilla59
x86_64
Linux
Dependency tree / graph

Firefox Tracking Flags

(firefox58 wontfix, firefox59 fixed)

Details

Attachments

(1 attachment)

Assignee

Description

2 years ago
I would like to upgrade the Clang we use for our ASan builds to Clang Trunk because it has several improvements related to memory usage that are not yet in Clang 5.0 (according to kcc), but which we need for the ASan Nightly Project.

My understanding is that I can simply add a build job definition "linux64-clang-trunk" to taskcluster/ci/toolchain/linux.yml, just like we did for Clang 5 recently.

Once I have that, I guess it is sufficient to change "linux64-clang" to the job I added, for all the ASan builds in taskcluster/ci/build/linux.yml.

Mike, can you confirm that these steps are correct? Am I missing something that I should be aware of? Thanks!
Flags: needinfo?(mh+mozilla)
Yes, but please don't call it clang-trunk, because that would kind of imply it's always on trunk, while it will be some version fixed in time. Call it clang-6 or clang-6-pre.
Flags: needinfo?(mh+mozilla)
Assignee

Updated

2 years ago
Depends on: 1416183
Assignee

Updated

2 years ago
Depends on: 1416185
Assignee

Updated

2 years ago
Depends on: 1415782
Comment hidden (mozreview-request)
Assignee

Comment 3

2 years ago
(In reply to Christian Holler (:decoder) from comment #2)
> Created attachment 8927809 [details]

The attached patch does the following things:

* Adds a clang-6-pre build for linux64 (Clang Trunk revision that was current when I wrote the patch)
* Adds a patch for the ASan runtime in compiler-rt that allows ASan to look up the llvm-symbolizer binary next to the firefox binary (default is CWD and PATH only)
* Switches all ASan Linux builds to the new clang-6-pre
* Disables two new warnings (-Wunused-private-field and -Wdeprecated-register) until the follow-up bugs (bug 1416183 and bug 1416185) are fixed

This is green on try with the patches from bug 1415782 on top (thanks Julian!).

The compiler-rt patch is important for the ASan Nightly project because in testing, we ended up with unsymbolized traces in the backend (and we cannot expect people to install llvm-symbolizer into PATH or CWD). I missed this earlier in testing because I always started the Firefox binary after changing to the containing firefox/ directory, so it is CWD. The patch is Linux only and I've already asked the ASan devs if this can be implemented. If they decide to implement this, then we can simply remove our patch. Otherwise, we will have to find another way to do this (e.g. by hacking the same code into __asan_default_options in mozglue/build/ but that option doesn't seem very pleasant if we can have this use case supported by compiler-rt natively).

In a follow-up bug, I will then enable the scribble feature (overwrites free'd memory to detect more uafs) and possibly tune some memory options if necessary, but I wanted to do that in a separate bug because some of these changes also affect performance and might be asan-reporter only.

Comment 4

2 years ago
mozreview-review
Comment on attachment 8927809 [details]
Bug 1415689 - Add Clang 6 (pre) and use it for ASan builds.

https://reviewboard.mozilla.org/r/199104/#review204534

Looks pretty good, just a few things to fix.

::: build/build-clang/find_symbolizer_linux.patch:1
(Diff revision 1)
> +diff --git a/compiler-rtlib/sanitizer_common/sanitizer_file.cc b/compiler-rt/lib/sanitizer_common/sanitizer_file.cc

Can you provide some descriptive comment, either in the patch itself, or prior to the `diff --git` line, so somebody doesn't have to trawl through blame to figure out why this patch was added?

Are we submitting this patch upstream?

::: build/build-clang/find_symbolizer_linux.patch:22
(Diff revision 1)
> +     if (*end == '\0') break;
> +     beg = end + 1;
> +   }
> ++
> ++#if SANITIZER_LINUX
> ++  internal_readlink("/proc/self/exe", buffer.data(), kMaxPathLength);

Can this call fail?  I know some people run without `/proc` mounted...  We should either handle failure here or use something that can handle failure gracefully.

::: build/unix/mozconfig.asan:16
(Diff revision 1)
> +# These can be removed once bugs 1416183 and 1416185 are fixed
> +export CFLAGS="$CFLAGS -Wno-unused-private-field -Wno-deprecated-register"
> +export CXXFLAGS="$CXXFLAGS -Wno-unused-private-field -Wno-deprecated-register"

Let's just not commit this patch until the dependent bugs are fixed, please?
Attachment #8927809 - Flags: review?(nfroyd)
Assignee

Comment 5

2 years ago
(In reply to Nathan Froyd [:froydnj] from comment #4)

> 
> ::: build/build-clang/find_symbolizer_linux.patch:1
> (Diff revision 1)
> > +diff --git a/compiler-rtlib/sanitizer_common/sanitizer_file.cc b/compiler-rt/lib/sanitizer_common/sanitizer_file.cc
> 
> Can you provide some descriptive comment, either in the patch itself, or
> prior to the `diff --git` line, so somebody doesn't have to trawl through
> blame to figure out why this patch was added?

Yes, I can do that on Thursday when I'm back from PTO.

> 
> Are we submitting this patch upstream?


I am discussing with upstream how we should handle this. They asked for the patch, but in order to make this upstream, they probably would want a platform independent solution so making this work for upstream might take longer. Also they might request changes to the way I'm doing this here. I just implemented it such that it works for the ASan Nightly Project and the project is unblocked (because not getting symbolized traces is a hard blocker).

> 
> ::: build/build-clang/find_symbolizer_linux.patch:22
> (Diff revision 1)
> > +     if (*end == '\0') break;
> > +     beg = end + 1;
> > +   }
> > ++
> > ++#if SANITIZER_LINUX
> > ++  internal_readlink("/proc/self/exe", buffer.data(), kMaxPathLength);
> 
> Can this call fail?  I know some people run without `/proc` mounted...  We
> should either handle failure here or use something that can handle failure
> gracefully.

You're right. A simple return nullptr on failure will do here, I will add this. Thanks!


> 
> ::: build/unix/mozconfig.asan:16
> (Diff revision 1)
> > +# These can be removed once bugs 1416183 and 1416185 are fixed
> > +export CFLAGS="$CFLAGS -Wno-unused-private-field -Wno-deprecated-register"
> > +export CXXFLAGS="$CXXFLAGS -Wno-unused-private-field -Wno-deprecated-register"
> 
> Let's just not commit this patch until the dependent bugs are fixed, please?

I disagree, unless the patch in bug 1416183 is reviewed until I'm back. Looking at comments like https://bugzilla.mozilla.org/show_bug.cgi?id=1416183#c4 it seems that fixing these is more effort. I am not willing to block such an important project (and the work on bug 1404860) on such kind of refactorings. I want this project to move forward as quickly as possible and since we are only working on the ASan builds here (and not any kind of production/release builds), I think that's a fair requirement.
Flags: needinfo?(nfroyd)
(In reply to Christian Holler (:decoder) from comment #5)
> (In reply to Nathan Froyd [:froydnj] from comment #4)
> > ::: build/unix/mozconfig.asan:16
> > (Diff revision 1)
> > > +# These can be removed once bugs 1416183 and 1416185 are fixed
> > > +export CFLAGS="$CFLAGS -Wno-unused-private-field -Wno-deprecated-register"
> > > +export CXXFLAGS="$CXXFLAGS -Wno-unused-private-field -Wno-deprecated-register"
> > 
> > Let's just not commit this patch until the dependent bugs are fixed, please?
> 
> I disagree, unless the patch in bug 1416183 is reviewed until I'm back.
> Looking at comments like
> https://bugzilla.mozilla.org/show_bug.cgi?id=1416183#c4 it seems that fixing
> these is more effort. I am not willing to block such an important project
> (and the work on bug 1404860) on such kind of refactorings. I want this
> project to move forward as quickly as possible and since we are only working
> on the ASan builds here (and not any kind of production/release builds), I
> think that's a fair requirement.

It looks like both of these are moving forward quickly enough that removing the suggested block of code is reasonable.
Flags: needinfo?(nfroyd)
Comment hidden (mozreview-request)
Assignee

Comment 8

2 years ago
(In reply to Christian Holler (:decoder) from comment #7)

> Review request updated; see interdiff:
> https://reviewboard.mozilla.org/r/199104/diff/1-2/


Confirmed that no more warnings are popping up after the warning fixes from the bug dependencies here, so I removed the -Wno flags as requested.

I also added comments both inside the patch code as well as on the top of the patch, explaining why we are patching this right now. We will have to see then if we stick to this patch or trade it for another solution later.

As for landing, we still have to wait for bug 1415782 to be fixed or disable that test with newer Clang if a fix is not feasible in time.

Comment 9

2 years ago
mozreview-review
Comment on attachment 8927809 [details]
Bug 1415689 - Add Clang 6 (pre) and use it for ASan builds.

https://reviewboard.mozilla.org/r/199104/#review205706

WFM, thank you for testing with the flags removed!
Attachment #8927809 - Flags: review?(nfroyd) → review+
Assignee

Updated

2 years ago
Blocks: 1419371

Comment 10

2 years ago
Pushed by choller@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8d6fd02420f2
Add Clang 6 (pre) and use it for ASan builds. r=froydnj

Comment 11

2 years ago
Backout by aiakab@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0fd137f9b3fe
Backed out changeset 8d6fd02420f2 for failing gtests on request from "decoder" on a CLOSED TREE

Comment 12

2 years ago
Pushed by choller@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/bf902590846a
Add Clang 6 (pre) and use it for ASan builds. r=froydnj
Assignee

Updated

2 years ago
Depends on: 1419608

Comment 13

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/bf902590846a
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59

Updated

Last year
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.