4
  • CentOS Linux release 7.6.1810 (Core)
  • g++ (GCC) 6.5.0
  • libasan3-6.3.1-3.1.el6.x86_64

I'm using AddressSanitizer to detect memory error. Unlike the common case, I need to build a rpm package rather than compile source code and run it directly. I have the testing code below:

#include <iostream>
#include <string.h>

using namespace std;

//void test3(char*) __attribute__((no_sanitize_address));
//__attribute__((no_sanitize_address))
void test3(char *p){
    delete[] p;
    cout << *p << endl;
    cout << "test3" << endl;
}

//__attribute__((no_sanitize_address))
void test2(char *ptr, char *p){
    if(memcmp(ptr,p,6) == 0){
        cout << "Yes" << endl;
    }
    cout << "test2" << endl;
}

int main(){
    char *p = new char[5];
    char *ptr = new char[6];
    test2(ptr, p);
    test3(p);
    delete[] ptr;
    return 0;
}

The compiling flags are -fsanitize=address -fno-omit-frame-pointer -fsanitize-recover=address -g -pipe -rdynamic -Wl,--build-id. Then I use rpmbuild to construct the rpm packages below:

Wrote: /root/rpmbuild/RPMS/x86_64/main_test-1.0.0-1.x86_64.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/main_test-debuginfo-1.0.0-1.x86_64.rpm

After installing the main_test and main_test-debuginfo, I run main. Now the problem is that Asan dosen't report any source file lines.

=================================================================
==39137==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eff5 at pc 0x7ffff6ecd328 bp 0x7fffffffe350 sp 0x7fffffffdb00
READ of size 6 at 0x60200000eff5 thread T0
    #0 0x7ffff6ecd327  (/usr/lib64/libasan.so.3+0x8d327)
    #1 0x400ee2 in test2(char*, char*) (/usr/local/bin/main+0x400ee2)
    #2 0x400f58 in main (/usr/local/bin/main+0x400f58)
    #3 0x7ffff62763d4 in __libc_start_main (/usr/lib64/libc.so.6+0x223d4)
    #4 0x400d58  (/usr/local/bin/main+0x400d58)

0x60200000eff5 is located 0 bytes to the right of 5-byte region [0x60200000eff0,0x60200000eff5)
allocated by thread T0 here:
    #0 0x7ffff6f02e70 in operator new[](unsigned long) (/usr/lib64/libasan.so.3+0xc2e70)
    #1 0x400f33 in main (/usr/local/bin/main+0x400f33)
    #2 0x7ffff62763d4 in __libc_start_main (/usr/lib64/libc.so.6+0x223d4)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib64/libasan.so.3+0x8d327) 
...

However, the expectation is:

=================================================================
==36210==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eff5 at pc 0x7ffff6ecd328 bp 0x7fffffffe370 sp 0x7fffffffdb20
READ of size 6 at 0x60200000eff5 thread T0
    #0 0x7ffff6ecd327  (/usr/lib64/libasan.so.3+0x8d327)
    #1 0x400ee2 in test2(char*, char*) /home/matt/main_test-1.0.0/main.cpp:17
    #2 0x400f58 in main /home/matt/main_test-1.0.0/main.cpp:27
    #3 0x7ffff62763d4 in __libc_start_main (/usr/lib64/libc.so.6+0x223d4)
    #4 0x400d58  (/home/matt/main_test-1.0.0/main+0x400d58)

0x60200000eff5 is located 0 bytes to the right of 5-byte region [0x60200000eff0,0x60200000eff5)
allocated by thread T0 here:
    #0 0x7ffff6f02e70 in operator new[](unsigned long) (/usr/lib64/libasan.so.3+0xc2e70)
    #1 0x400f33 in main /home/matt/main_test-1.0.0/main.cpp:24
    #2 0x7ffff62763d4 in __libc_start_main (/usr/lib64/libc.so.6+0x223d4)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib64/libasan.so.3+0x8d327) 
...

It seems that Asan cannot link the source file. I'm confused with what went wrong. Is there any way to solve it?

Thank U!

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
Matt
  • 41
  • 1
  • »» Asan cannot link «« : You have no libasan.so ? .......... Example `# cd /usr/lib64/ && ln -s libasan.so.3.0.0 libasan.so`. ......... But then again, your "gcc / g++ 6.5.0 install" could provide libasan.so ? – Knud Larsen Sep 30 '21 at 12:55

1 Answers1

2

I'm confused with what went wrong.

AddressSanitizer runtime is probably not set up to use separate debug info.

[Update: @fche comments that asan/libbacktrace facility gained separate-debuginfo support in gcc 10.1 or so]

There is no fundamental reason it can't, but this isn't how most developers use AddressSanitizer.

Is there any way to solve it?

You have a few options:

  1. Disable strip and separate debug info generation in rpmbuild. This answer may be useful.
  2. Use addr2line -fe /path/to/unstripped/binary 0x400ee2 0x400f58 ... to recover source file/line info after the fact.
Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • It appears as though the asan/libbacktrace facility gained separate-debuginfo support in gcc 10.1 or so. I hope they also get debuginfod support before too long, so asan could snarf the split debuginfo right out of your -debuginfo rpm, even without installing it. https://github.com/ianlancetaylor/libbacktrace/issues/79 – fche Oct 07 '21 at 20:21