[aarch 64 Linux] Differences in ASAN Output Between x86 and ARM Architectures: Indirect Leaks Only Detected in libc on ARM

[UnbelievableGBS]

I am encountering a discrepancy in ASAN's behavior when analyzing the same codebase on x86 and ARM architectures. While ASAN works as expected on x86, providing detailed stack traces and correctly linking memory issues to specific lines in my application code, the output on ARM is significantly different.

Problem Description:
x86 Output: ASAN provides detailed stack traces that directly point to the specific lines of code in my application where memory issues occur.
ARM Output: ASAN's output on ARM focuses almost entirely on indirect leaks detected in the standard C library (libc). It fails to link these issues to the relevant application code, instead only reporting leaks in functions like malloc and re_compile_pattern.

ASAN Options:
I am using the following ASAN_OPTIONS for both architectures:
ASAN_OPTIONS=halt_on_error=0:log_path=/Log/vcn/ivs_mu/asan.report:verbosity=0:detect_leaks=1

Howeverm, ASAN behaves as expected on x86 but fails to provide meaningful information on ARM, focusing only on standard library functions without linking to the application code.

Here are some screenshots of the results of the memory analysis in the arm architecture:

Questions:

• Is this a known issue with ASAN on ARM architectures?

• Are there any specific configurations or patches that could help improve ASAN's behavior on ARM?

• Could this be related to differences in the standard C library implementations between architectures?

• What could be the cause of this result? Is there any solution to this?

[vitalybuka]

That's possible, LSAN can't guaranty detecting all leaks.
Pointer can be stuck and some register or padding on the stack and LSAN will assume it's alive.
And this can be platform specific.