zclllyybb commented on issue #64163:
URL: https://github.com/apache/doris/issues/64163#issuecomment-4637640363

   Breakwater-GitHub-Analysis-Slot: slot_d049339f856b
   
   Initial analysis from current upstream `master`:
   
   The report looks valid and code-level, not just a local toolchain problem. 
On current `master`, `be/CMakeLists.txt` sets the LSAN build flags to 
`-fsanitize=leak -DLEAK_SANITIZER`, and the LSAN link path brings in the LSAN 
runtime. In `be/src/common/phdr_cache.cpp`, the current guard only treats 
`ADDRESS_SANITIZER` as a case where `__lsan_ignore_object` is provided 
externally; otherwise it emits a strong no-op definition. Therefore an LSAN 
build that does not define `ADDRESS_SANITIZER` can link both Doris' local 
definition and LLVM's `libclang_rt.lsan` definition of `__lsan_ignore_object`, 
which matches the duplicate symbol reported here.
   
   The UBSAN part does not appear to be necessary for the duplicate symbol 
itself. The key condition is: LSAN runtime is linked while `ADDRESS_SANITIZER` 
is not defined. I also confirmed the secondary gap: 
`be/src/util/debug/leak_annotations.h` currently enables 
`ANNOTATE_LEAKING_OBJECT_PTR` only for `__has_feature(address_sanitizer)`, so 
LSAN-only builds do not use the intended leak-ignore annotation path.
   
   PR #64164 is in the right direction: remove the local `__lsan_ignore_object` 
definition from `phdr_cache.cpp` and route the intentional PHDR cache leak 
through `ANNOTATE_LEAKING_OBJECT_PTR`. One review detail I would check before 
merging is that the annotation guard covers Doris' own sanitizer defines as 
well as compiler feature checks, for example `LEAK_SANITIZER` / 
`ADDRESS_SANITIZER` in addition to `__has_feature(leak_sanitizer)` / 
`__has_feature(address_sanitizer)`, because Doris' CMake files explicitly 
define those macros for sanitizer build types.
   
   Suggested next steps:
   
   1. Review or merge #64164, or an equivalent fix that never defines 
`__lsan_ignore_object` when LSAN runtime is linked.
   2. Validate at least a clean `CMAKE_BUILD_TYPE=LSAN` BE UT link, and also 
the exact LSAN+UBSAN build command used in this report if it is a custom 
sanitizer combination.
   3. If maintainers want independent reproduction, the only missing 
information is the exact build invocation/environment: compiler path/version, 
`build.sh` or CMake command, `CMAKE_BUILD_TYPE`, and any `EXTRA_CXX_FLAGS` or 
link flags used to combine LSAN with UBSAN.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to