Fix dlsym issue (#6048 -> v2) #6051
Closed
+152
−35
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR addresses the issue #6045 When using the `dlsym` function, the compiler adds in the import symbols table that we need the `dlsym` symbol. Before being a universal binary (same binary used for glibc-based linux and musl-libc-based linux) and the compiler added in a `DT_NEEDED` section the library `libdl.so` (the library containing `dlsym`). When the wrapper is loaded, it will look through all the `DT_NEEDED` sections to find a library that contains the `dlsym` symbol. Since being a universal binary, the `DT_NEEDED` sections are removed (part of being universal) and we have to resolve by hand needed symbols (`dlsym`, `pthread_once` ..). If we use `dlsym` (or other symbol), we will hit this issue. - use `__dd_dlsym` instead Added a snapshot test using `nm` that verifies that the undefined symbols in the universal binary haven't changed. It's equivalent to running ```bash nm -D Datadog.Linux.ApiWrapper.x64.so | grep ' U ' | awk '{print $2}' | sed 's/@.*//' | sort ``` but done using Nuke instead. It would probably make sense for this to be a "normal" test in the native tests, but given it has a dependency on `nm`, which is _definitely_ available in the universal build dockerfile it was quicker and easier to get this up and running directly. When it fails, it prints the diff and throws an exception, e.g. ```bash System.Exception: Found differences in undefined symbols (dlsym) in the Native Wrapper library. Verify that these changes are expected, and will not cause problems. Removing symbols is generally a safe operation, but adding them could cause crashes. If the new symbols are safe to add, update the snapshot file at C:\repos\dd-trace-dotnet\tracer\test\snapshots\native-wrapper-symbols-x64.verified.txt with the new values ``` This will be hotfixed onto 3.3.1 and 2.59.1 --------- Co-authored-by: Andrew Lock <andrew.lock@datadoghq.com>
andrewlock
added
type:bug
area:profiler
|
This doesn't compile, as these are not universal binaries. However, we can't reproduce the #6044 issue in 2.x, so closing this as not required |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of changes
This PR addresses the issue #6045
Reason for change
When using the
dlsymfunction, the compiler adds in the import symbols table that we need thedlsymsymbol.Before being a universal binary (same binary used for glibc-based linux and musl-libc-based linux) and the compiler added in a
DT_NEEDEDsection the librarylibdl.so(the library containingdlsym). When the wrapper is loaded, it will look through all theDT_NEEDEDsections to find a library that contains thedlsymsymbol.Since being a universal binary, the
DT_NEEDEDsections are removed (part of being universal) and we have to resolve by hand needed symbols (dlsym,pthread_once..).If we use
dlsym(or other symbol), we will hit this issue.Implementation details
__dd_dlsyminsteadTest coverage
Added a snapshot test using
nmthat verifies that the undefined symbols in the universal binary haven't changed. It's equivalent to runningbut done using Nuke instead. It would probably make sense for this to be a "normal" test in the native tests, but given it has a dependency on
nm, which is definitely available in the universal build dockerfile it was quicker and easier to get this up and running directly. When it fails, it prints the diff and throws an exception, e.g.Other details
This is a hotfix of