[SERVER-45677] enable libunwind by default where available Created: 21/Jan/20 Updated: 29/Oct/23 Resolved: 14/Feb/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.4 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Billy Donahue | Assignee: | Billy Donahue |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Sprint: | Dev Tools 2020-02-10, Dev Platform 2020-01-27, Dev Tools 2020-02-24 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
Currently only those evergreen builders that explicitly add --use-libunwind to their scons invocations will get libunwind. We should flip the switch to make it on by default if TARGET_OS and TARGET_ARCH etc indicate that it will work. |
| Comments |
| Comment by Andrew Morrow (Inactive) [ 18/Feb/20 ] |
|
ravind.kumar - For now, and probably for 4.4, it is actually just x86_64 linux, but eventually probably all linux. And yes, it is a requirement, just like the openssl libraries. No restrictions on versioning, it just needs to be the system one for the distro. It applies to both tarball and RPM/DEB, but as you note RPM/DEB will have the dependency expressed and so it will be automatically installed if it isn't already. For tarballs, the user will need to ensure that the appropriate runtime package is installed. |
| Comment by Ravind Kumar (Inactive) [ 18/Feb/20 ] |
|
acm mathew.robinson just to make sure I understand correctly - for all Linux installations, the system must have liblzma installed? DO we have any restrictions or requirements on versioning here, or it just has to exist and/or be latest? Does this apply to tarball + RPM/DEB? I'm assuming that for installation via package manager it will be downloaded and installed automatically as a pre-req, but for tarball installations its on the user to install the package. |
| Comment by Githook User [ 14/Feb/20 ] |
|
Author: {'username': 'BillyDonahue', 'name': 'Billy Donahue', 'email': 'billy.donahue@mongodb.com'}Message:
|
| Comment by Billy Donahue [ 07/Feb/20 ] |
|
I think this tcmalloc interaction is definitely what's going on. I imagine some flakes would also appear from a similar interaction with recent Mutex diagnostics in debug builds. These diagnostics create backtraces on lock events. So debug builds would have slightly slower lock and unlock operations with libunwind. That would explain |
| Comment by Billy Donahue [ 07/Feb/20 ] |
|
About the "breaking" of the Linux DEBUG tests. Theory: libunwind's backtrace is slower than gcc's inferior backtrace. TCMalloc uses backtrace to implement heap profiling internally. The presence of libunwind makes debug builds of tcmalloc perform malloc more slowly. So tests that are flaky and depend on specific tcmalloc performance are breaking when libunwind is introduced. |
| Comment by Githook User [ 06/Feb/20 ] |
|
Author: {'name': 'William Schultz', 'username': 'will62794', 'email': 'william.schultz@mongodb.com'}Message: Revert " This reverts commit 969151e9ab69dcb53397cf40f810e718421db081. |
| Comment by William Schultz (Inactive) [ 06/Feb/20 ] |
|
This commit appears to have broken a number of required builders, primarily on Linux DEBUG it seems. Reverting it for now. |
| Comment by Githook User [ 05/Feb/20 ] |
|
Author: {'name': 'Billy Donahue', 'username': 'BillyDonahue', 'email': 'billy.donahue@mongodb.com'}Message:
|