FS#50366 - [clang] AddressSanitizer CHECK failed

Attached to Project: Arch Linux
Opened by A. K. (Misery) - Friday, 12 August 2016, 06:33 GMT
Last edited by Evangelos Foutras (foutrelis) - Thursday, 27 October 2016, 19:45 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Evangelos Foutras (foutrelis)
Bartłomiej Piotrowski (Barthalion)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
Since last upgrade of gcc-libs we cannot use the address sanitizer with clang++ anymore as it exits immediately.

Additional info:
* Upgrade gcc-libs 6.1.1-3 to 6.1.1-5



Steps to reproduce:
Compile a program with "-fsanitize=address" and run it.


==6022==AddressSanitizer CHECK failed: /build/llvm/src/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_rtl.cc:407 "((!asan_init_is_running && "ASan init calls itself!")) != (0)" (0x0, 0x0)
<empty stack>
This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Thursday, 27 October 2016, 19:45 GMT
Reason for closing:  Fixed
Additional comments about closing:  clang 3.9.0-1
Comment by Max Bruckner (FSMaxB) - Sunday, 14 August 2016, 11:30 GMT
I am experiencing the same problem with clang (without ++).
Comment by David Hows (da5id) - Monday, 15 August 2016, 02:40 GMT
Looks like this relates to the following upstream at LLVM. Does make it hard to do manual development work with fsanitize on Arch, as all attempts to run config scripts will fail initilaization.
https://reviews.llvm.org/D20235
https://llvm.org/bugs/show_bug.cgi?id=27310
Comment by blitz (blitz) - Tuesday, 16 August 2016, 15:17 GMT
This bug introduced by glibc-2.24.

Both clang or gcc produced binaries with -fsanitize={address,memory} fail to execute with glibc-2.24, whereas execute with 2.23.

https://sourceware.org/bugzilla/show_bug.cgi?id=20474
Comment by Peter Wu (Lekensteyn) - Monday, 29 August 2016, 19:27 GMT
Clang 3.9.0 is around the corner, it should be here next week
http://lists.llvm.org/pipermail/cfe-dev/2016-August/050564.html

In meantime, the same workarounds are possible:
- downgrade glibc (not recommended)
- use workaround in https://llvm.org/bugs/show_bug.cgi?id=27310#c8 (add extra symbols via the below gdb method as needed).

$ gdb -q -ex 'b _dl_signal_cerror' -ex r ./a.out
Breakpoint 1, 0x00007ffff7de92a0 in _dl_signal_cerror () from /lib64/ld-linux-x86-64.so.2
(gdb) p (char*)$rcx
$1 = 0x7fffffffdf30 "undefined symbol: __isoc99_printf"

Since the llvm bugs somehow needs a login now, I am pasting the source here:
cat >fixasan.c <<C
void __isoc99_printf() {}
void __isoc99_sprintf() {}
void __isoc99_snprintf() {}
void __isoc99_fprintf() {}
void __isoc99_vprintf() {}
void __isoc99_vsprintf() {}
void __isoc99_vsnprintf() {}
void __isoc99_vfprintf() {}
void __cxa_throw() {} // NEW
C
gcc fixasan.c -o fixasan.so -fPIC -shared -nostdlib
LD_PRELOAD=./fixasan.so ./main # NOTE: do not add GCC's libasan.so
Comment by A. K. (Misery) - Tuesday, 27 September 2016, 14:30 GMT
Any progress for clang 3.9?

Loading...