LeakSanitizer动态加载库回溯显示Unknown Module问题求助

Let's break down why you're seeing those <unknown module> entries in your LeakSanitizer backtrace and how to fix it. The core issue is that LeakSanitizer can't resolve symbols from your dynamically loaded library—usually because debug symbols are missing, or the runtime environment isn't set up to help ASAN find those symbols.

First, Understand the Root Causes #

The <unknown module> messages happen when:

• Your shared library was compiled without debug symbols (no -g flag) or had symbols stripped (via strip or -s compiler flag).
• LeakSanitizer can't locate the library file at runtime to resolve addresses to function names.
• There's a version mismatch between your compiler, ASAN runtime, and the symbolizer tool.

Step-by-Step Solutions #

1. Recompile Your Shared Library with Debug Symbols

Make sure you include the -g flag when compiling your dynamic library—this preserves debug symbols needed for symbolization. You can still keep optimizations with -O2 (just avoid -s or stripping later):

gcc -g -O2 -shared -o libyourlibrary.so yourlibrary.c

If you're using C++, replace gcc with g++ and adjust source/object files accordingly.

2. Configure Runtime Environment Variables

LeakSanitizer relies on external tools and paths to resolve symbols. Set these before running your program:

• Point to the correct symbolizer: ASAN uses llvm-symbolizer (or version-specific variants like llvm-symbolizer-14) to translate addresses to function names. Set the path explicitly:

  export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer
  

  If you don't have llvm-symbolizer installed, install it via your package manager (e.g., sudo apt install llvm on Debian/Ubuntu).
• Ensure ASAN can find your library: Add the directory containing your shared library to LD_LIBRARY_PATH so ASAN can locate it at runtime:

  export LD_LIBRARY_PATH=/path/to/your/library/directory:$LD_LIBRARY_PATH
  

3. Avoid Stripping Symbols from Your Library

If you've already stripped symbols from your library (e.g., using strip libyourlibrary.so), you'll need to use the unstripped version for debugging. Keep a copy of the library with debug symbols specifically for LeakSanitizer testing.

4. Verify Compiler/ASAN Version Compatibility

Make sure the compiler used to build your radiusd binary and shared library matches the version of ASAN you're using. Mismatched versions can cause symbolization failures. For example, if you built with clang-14, ensure your ASAN runtime and llvm-symbolizer are also version 14.

5. Run the Program with Correct Flags

Putting it all together, run your program like this to get proper symbolized backtraces:

ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer LD_LIBRARY_PATH=/path/to/libs ./radiusd

Verifying the Fix #

After making these changes, rerun your LeakSanitizer check. The backtrace should now show actual function names from your dynamic library instead of <unknown module>, replacing your original output:

Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x4e3e36 in malloc (/usr/sbin/radiusd+0x4e3e36)
#1 0x7fb406e95f69 in my_library_function (/path/to/libyourlibrary.so+0x12f69)
#2 0x7fb406eafc36 in another_function (/path/to/libyourlibrary.so+0x1dc36)
...

内容的提问来源于stack exchange，提问作者Arran Cudbard-Bell