Description
The following setup breaks our current assumptions in allocation profiling:
-
The executable resolves malloc from the global scope.
This typically means the system allocator (e.g., the one provided by libc) is used.
-
A shared library (libA) is loaded and defines its own allocator.
Under normal circumstances, this should not affect which allocator is used by the executable itself.
However, if libA is loaded with the RTLD_DEEPBIND flag, symbol resolution for malloc inside libA will prioritize its own definition rather than the global one.
As a result, libA and the main executable may end up using different allocators.
Impact
This creates a situation where malloc calls must be intercepted and dispatched to different allocator implementations depending on the originating call site.
Since this behavior is currently not handled by ddprof, it can result in allocator mismatches and potential crashes.
Description
The following setup breaks our current assumptions in allocation profiling:
The executable resolves malloc from the global scope.
This typically means the system allocator (e.g., the one provided by libc) is used.
A shared library (libA) is loaded and defines its own allocator.
Under normal circumstances, this should not affect which allocator is used by the executable itself.
However, if libA is loaded with the RTLD_DEEPBIND flag, symbol resolution for malloc inside libA will prioritize its own definition rather than the global one.
As a result, libA and the main executable may end up using different allocators.
Impact
This creates a situation where malloc calls must be intercepted and dispatched to different allocator implementations depending on the originating call site.
Since this behavior is currently not handled by ddprof, it can result in allocator mismatches and potential crashes.