Upgrade clang to 7.0.1
Categories
(Firefox Build System :: Toolchains, enhancement)
Tracking
(firefox66 fixed)
| Tracking | Status | |
|---|---|---|
| firefox66 | --- | fixed |
People
(Reporter: glandium, Assigned: glandium)
References
Details
Attachments
(1 file)
It was released a few days ago.
|
Assignee | |
Comment 1•5 years ago
|
||
Pushed by mh@glandium.org: https://hg.mozilla.org/integration/autoland/rev/4474a7665e47 Upgrade clang to 7.0.1. r=dmajor
|
||
Comment 3•5 years ago
|
||
Backed out 1 changesets (bug 1516374) for causing Linux asan browser chrome exceptions push that caused the backout: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&revision=4474a7665e47d2cca4719c748133ca514d0d7a2d failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&selectedJob=218916605&searchStr=linux%2Cx64%2Casan%2Cmochitests%2Cwith%2Ce10s%2Ctest-linux64-asan%2Fopt-mochitest-browser-chrome-e10s-1%2Cm-e10s%28bc1%29 backout: https://hg.mozilla.org/integration/autoland/rev/bbbcbd1f29680aaf228cbb791d095315c4398471
|
|
Assignee | |
Comment 4•5 years ago
|
||
I finally figured out what goes wrong, but I don't know yet exactly what the root cause is.
What goes wrong is that llvm-symbolizer requires more memory to do its work in some cases. In the order of 1GB instead of a few dozens MB. When Firefox exits, every single process that has been launched terminates, and for each of them that had leaks (most), a llvm-symbolizer process is launched. In many cases, that's 5 processes. Each sucking 1GB of memory. All at the same time. So there's an instant rush to have 5GB of memory available, on machines that only have 7.5GB physical memory and no swap, running an Ubuntu desktop environment, and Firefox with ASAN... so there isn't enough memory available. Subsequently, because of the rush of memory demand, and the lack of available memory, the kernel goes on a process killing spree, and ends up killing the worker, leaving us with no logs as to what just happened (bug 1516575 was filed to try to avoid the situation).
Now, and this is where things get fun: I've actually managed to have the problem on try with the current, non-upgraded clang 7. And for some reason it doesn't happen on integration branches. And here's another fun fact: it doesn't happen when sccache is disabled. But it still happens when sccache is enabled and clang is compiled such that sccache only gets cache misses. It also doesn't happen when sccache is patched to include the input file name in the hash it uses for the cache key. That's something I noticed in the failed builds with a different clang executable: some c++ files still had cache hits while most others didn't, and most of those with cache hits are files that once preprocessed are essentially empty (but have different sources).
At this point, my assumption is that the presence of those files makes a subtle difference in the debug info that makes llvm-symbolizer use more memory.
|
|
Assignee | |
Comment 5•5 years ago
|
||
It appears a try on current central doesn't create a libxul.so with a size multiple of 4KiB, so this would presumably not fail when landing again, independently of bug 1518726. Also, considering it's a libxul size problem that's independent of the clang version, it could just as well happen with the current version, so let's go ahead with a relanding.
Pushed by mh@glandium.org: https://hg.mozilla.org/integration/autoland/rev/4728285e13e4 Upgrade clang to 7.0.1. r=dmajor
|
||
Comment 7•5 years ago
|
||
| bugherder | ||
|
||
Comment 8•5 years ago
|
||
Backed out changeset 4728285e13e4 (Bug 1516374) for causing coverage build bustages. a=backout
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=220841218&repo=mozilla-central&lineNumber=1212
Backout: https://hg.mozilla.org/mozilla-central/rev/8da9aee6dae7fba2517cce3f67866b2c0ab01949
The code coverage mozconfigs use hardcoded paths to 7.0.0 libs: https://searchfox.org/mozilla-central/search?q=clang%2F7.0.0&case=false®exp=false&path=
Maybe these could benefit from the "" trick: https://searchfox.org/mozilla-central/search?q=clang%2F
|
||
Comment 10•5 years ago
|
||
Can we just fix things so that configure automatically puts that directory into LDFLAGS when we --enable-coverage?
|
|
Assignee | |
Comment 11•5 years ago
|
||
I'll go with the no-brainer, and will file a bug for comment 10.
|
||
Comment 12•5 years ago
|
||
Pushed by mh@glandium.org: https://hg.mozilla.org/integration/autoland/rev/1212d77a97b1 Upgrade clang to 7.0.1. r=dmajor
|
|
Assignee | |
Comment 13•5 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #11)
I'll go with the no-brainer, and will file a bug for comment 10.
That bug already exists: bug 1476339
|
||
Comment 14•5 years ago
|
||
| bugherder | ||
Description
•