[SERVER-50125] UBSAN with ccache doesn't always respect -fsanitize-blacklist options Created: 05/Aug/20 Updated: 29/Oct/23 Resolved: 03/Sep/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Build |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0, 4.4.2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Spencer Jackson | Assignee: | Ryan Egesdahl (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Backport Requested: |
v4.4
|
||||
| Sprint: | Dev Platform 2020-08-24, Dev Platform 2020-09-07 | ||||
| Participants: | |||||
| Description |
|
When I build the server on my evergreen workstation with AUBSAN, it crashes with messages like the following:
I've also seen messages from Snappy. These errors are surprising, as they're in files covered by etc/ubsan.blacklist which I would expect to suppress them. On a hunch, I tried disabling ccache, and the resulting mongod binaries appear to work. I found this Github issue which appears to describe the problem: https://github.com/ccache/ccache/issues/174 It was tagged as being a part of their 3.5 epic. The version of ccache on the evergreen workstations appears to be version 3.4.1. The SCons invokation which produced the failing binaries:
The corrected invokation:
|
| Comments |
| Comment by Githook User [ 13/Oct/20 ] |
|
Author: {'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}Message: Merging the following fixes into the stable version of the build tools
(cherry picked from commit 78bb3f3c8a658a5a9fec8d55864e426382f68bd0) |
| Comment by Githook User [ 07/Oct/20 ] |
|
Author: {'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}Message: Merging the following fixes into the stable version of the build tools
(cherry picked from commit 78bb3f3c8a658a5a9fec8d55864e426382f68bd0) |
| Comment by Githook User [ 07/Oct/20 ] |
|
Author: {'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}Message: Some versions of ccache do not know how to handle clang's
(cherry picked from commit 37276b21f4dbd66f913e8d49577fd4b1c4eafbf9) |
| Comment by Githook User [ 06/Oct/20 ] |
|
Author: {'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}Message: Merging the following fixes into the stable version of the build tools |
| Comment by Githook User [ 03/Sep/20 ] |
|
Author: {'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}Message: Some versions of ccache do not know how to handle clang's
|
| Comment by Ryan Egesdahl (Inactive) [ 05/Aug/20 ] |
|
ccache added support for hashing -fsanitize-blacklist in version 3.5 with this PR: There is still a pending issue open to handle multiple -fsanitize-blacklist options as well: The -fsanitize-blackist option changes the resulting binary object output by the compiler. These missing options mean that someone using ccache who has compiled without -fsanitize-blacklist and then with it (or vice/versa) may see the wrong object being pulled from the cache. For the record, Ubuntu 18.04 currently still uses ccache version 3.4.1, so it doesn't support hashing -fsanitize-blacklist at all. Ubuntu 20.04 has version 3.7.7, so it supports only one instance of -fsanitize-blacklist. There is a workaround documented in the issue associated with PR #258 that we might be able to use here: Basically, we just add the paths to the blacklist files to the CCACHE_EXTRAFILES environment variable so ccache alters the hash according to whether they are in use. This should work regardless of the ccache version. |