AddressSanitizer error when using libc++ from apt.llvm.org

[yachoor]

Recently (since around 10th November) my AddressSanitizer builds started failing with alloc-dealloc-mismatch in libc++ and libc++abi:

=================================================================
==1434378==ERROR: AddressSanitizer: alloc-dealloc-mismatch (operator new vs free) on 0x604000000090
    #0 0x49eeb2 in free (/home/jchorko/test/a.out+0x49eeb2) (BuildId: 91122a1096e4968986fc59eafa1f74bea3cd2fbf)
    #1 0x7f67be96705d in std::range_error::~range_error() (/lib/x86_64-linux-gnu/libc++abi.so.1+0x2505d) (BuildId: ec7530f4e7d3b344a16572b564800c87973d8d4e)
    #2 0x7f67be969453 in __cxa_end_catch (/lib/x86_64-linux-gnu/libc++abi.so.1+0x27453) (BuildId: ec7530f4e7d3b344a16572b564800c87973d8d4e)
    #3 0x4dc076 in main (/home/jchorko/test/a.out+0x4dc076) (BuildId: 91122a1096e4968986fc59eafa1f74bea3cd2fbf)
    #4 0x7f67be5df564 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x28564) (BuildId: 2b48299781548c9bc452eac6df39902547c884ed)
    #5 0x41d38d in _start (/home/jchorko/test/a.out+0x41d38d) (BuildId: 91122a1096e4968986fc59eafa1f74bea3cd2fbf)

0x604000000090 is located 0 bytes inside of 34-byte region [0x604000000090,0x6040000000b2)
allocated by thread T0 here:
    #0 0x4d997d in operator new(unsigned long) (/home/jchorko/test/a.out+0x4d997d) (BuildId: 91122a1096e4968986fc59eafa1f74bea3cd2fbf)
    #1 0x7f67be9d593f in std::runtime_error::runtime_error(char const*) (/lib/x86_64-linux-gnu/libc++.so.1+0x4f93f) (BuildId: bf8e70f0936248992f696c1e5117e394b302423d)
    #2 0x7f67be5df564 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x28564) (BuildId: 2b48299781548c9bc452eac6df39902547c884ed)

SUMMARY: AddressSanitizer: alloc-dealloc-mismatch (/home/jchorko/test/a.out+0x49eeb2) (BuildId: 91122a1096e4968986fc59eafa1f74bea3cd2fbf) in free
==1434378==HINT: if you don't care about these errors you may set ASAN_OPTIONS=alloc_dealloc_mismatch=0
==1434378==ABORTING

This is example code that triggers it:

#include <stdexcept>
#include <cstdio>

int main() {
  try {
    throw std::runtime_error("Bad value");
  } catch (const std::runtime_error& e) {
    printf("%s\n", e.what());
  }

  return 0;
}

Compiled and run with:
clang++ -fno-omit-frame-pointer -stdlib=libc++ -fsanitize=address test.cpp && ./a.out

Compiler (and corresponding libc++/libc++abi packages) version:

Ubuntu clang version 14.0.0-++20211214104537+47eec789ed9c-1~exp1~20211214104630.167
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

[mkurdej]

It looks like a mislink, because you've thrown a runtime_error (which gets constructed with new), but a range_error (deriving from runtime_error) is destructed.

[davits]

Got the same issue today, minimized it to this:

cat << EOF > example.cpp
#include <stdexcept>

int main(int, char**) {
        std::runtime_error e("blabla");
        return 0;
}
EOF
clang++ -fsanitize=address -stdlib=libc++ example.cpp -o out && ./out

About the strange destruction stack in the sanitizer error report.
Here is excerpt from nm -D libc++abi.so

0000000000024320 T _ZNSt11range_errorD0Ev
0000000000024230 T _ZNSt11range_errorD1Ev
0000000000024230 T _ZNSt11range_errorD2Ev

0000000000024270 T _ZNSt13runtime_errorD0Ev
0000000000024230 T _ZNSt13runtime_errorD1Ev
0000000000024230 T _ZNSt13runtime_errorD2Ev

0000000000024340 T _ZNSt14overflow_errorD0Ev
0000000000024230 T _ZNSt14overflow_errorD1Ev
0000000000024230 T _ZNSt14overflow_errorD2Ev

0000000000024360 T _ZNSt15underflow_errorD0Ev
0000000000024230 T _ZNSt15underflow_errorD1Ev
0000000000024230 T _ZNSt15underflow_errorD2Ev

Looks like there is a size optimization for libc++abi.so, which merges "complete/base object destructors" of these exception classes into one, because they all do the same thing.

Also can see operator delete(void*) call in source code and assembly of ~runtime_error(), but when stopping on free, there is no operator delete(void*) on the stack, not sure why it is happening, but seems like it is the reason for sanitizer to freak out.

(lldb) breakpoint set --method std::runtime_error::~runtime_error
(lldb) b free

output (note destructor name):

* thread #1, name = 'out', stop reason = instruction step over
    frame #0: 0x00007ffff7e99259 libc++abi.so.1`std::overflow_error::~overflow_error() + 41
libc++abi.so.1`std::overflow_error::~overflow_error:
->  0x7ffff7e99259 <+41>: callq  0x7ffff7e9b060            ; operator delete(void*)
    0x7ffff7e9925e <+46>: movq   %rbx, %rdi
    0x7ffff7e99261 <+49>: popq   %rbx
    0x7ffff7e99262 <+50>: jmp    0x7ffff7e990d0            ; std::bad_exception::~bad_exception()

(lldb) bt
* thread #1, name = 'out', stop reason = breakpoint 2.3
  * frame #0: 0x00007ffff7bb3700 libc.so.6`__GI___libc_free(mem=0x00005555555592a0) at malloc.c:3087:1
    frame #1: 0x00007ffff7e9925e libc++abi.so.1`std::overflow_error::~overflow_error() + 46
    frame #2: 0x0000555555555186 out`main + 54
    frame #3: 0x00007ffff7b3d0b3 libc.so.6`__libc_start_main(main=(out`main), argc=1, argv=0x00007fffffffe018, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffe008) at libc-start.c:308:16
    frame #4: 0x000055555555508e out`_start + 46

[davits]

Got the no operator delete(void*) on stack part.
operator delete(void*) just jumps to free, because argument and return values of these function are the same, so basically frame of operator delete(void*) is replaced with free.

Process 1182369 stopped
* thread #1, name = 'out', stop reason = instruction step into
    frame #0: 0x00007ffff7e9b060 libc++abi.so.1`operator delete(void*)
libc++abi.so.1`operator delete:
->  0x7ffff7e9b060 <+0>: jmp    0x7ffff7e83090            ; symbol stub for: free
    0x7ffff7e9b065:      nopw   %cs:(%rax,%rax)

[kysucix]

We're also experiencing the same errors in out tests throwing exceptinos.

[kysucix]

Related, and more active issue: #59432

[firewave]

This was fixed via #59432.