Bug#842642: clang-3.9: memory sanitizer segfaults immediately

Fri Nov 11 16:02:44 UTC 2016

Hi, you messed up the order, look in the series file from the attachment.
You only need those two patches (in this order), third is already
included in 3.8.1:

upstream-msan-prevent-initialization-failure.diff
upstream-asan-msan-fix-reallocation-logic.diff

if you want you can refresh them with quilt, but they apply cleanly
for me (with some other linenumbers)

2016-11-11 16:23 GMT+01:00 Sylvestre Ledru <s at mozilla.com>:
> I could apply upstream-msan-prevent-initialization-failure.diff  to 3.8 but
> not the two others, could you share yours?
> Thanks
> S
>
>
> Le 11/11/2016 à 09:52, Norbert Lange a écrit :
>>
>> The same 2 patches also apply to toolchain 3.8.1-15 (with some
>> offsets), but I haven`t testing building it
>>
>> 2016-11-11 1:25 GMT+01:00 Norbert Lange <nolange79 at gmail.com>:
>>>
>>> BTW. make check-sanitizer would have likely found this issue, might
>>> want to enable it?
>>> I believe it knows which sanitizers should work
>>>
>>> 2016-11-11 0:46 GMT+01:00 Norbert Lange <nolange79 at gmail.com>:
>>>>
>>>> Tags: patch
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I got it working, seems that from the 3 related patched, one is already
>>>> applied.
>>>> The attached archive is the 3 patches and a edited "series" file,
>>>> it should be painless for you to integrate it into the debian/patches
>>>> directory for 3.9
>>>>
>>>> I did not try with 3.8 yet (possibly more difficult), building llvm
>>>> takes quite a while.
>>>>
>>>> Kind Regards,
>>>> Norbert
>>>>
>>>> 2016-11-09 11:04 GMT+01:00 Norbert Lange <nolange79 at gmail.com>:
>>>>>
>>>>> Hi,
>>>>>
>>>>> researched a bit further and the same compiled programm will run fine
>>>>> on debian jessie.
>>>>> I tracked it down to being caused by a newer glibc version [1][2],
>>>>> apparently during loading of shared libs, glibc can now allocate
>>>>> memory which messes up sanitzers (mostly in more subtile ways than the
>>>>> memory sanitizer).
>>>>>
>>>>> The result is, that if stretch will ship with the current glibc, clang
>>>>> and gcc (I dont think its patched there either), then the sanitizers
>>>>> won`t be usable.
>>>>> 1) revert the fix in glibc. Would have the advantage that "sanitized"
>>>>> binaries compiled from current and older clang/gcc versions will work
>>>>> 2) adopt the fixed from upstream [3][4] (possibly more) into clang
>>>>> (and possibly gcc).
>>>>> or maybe both?
>>>>>
>>>>> Kind Regards,
>>>>> Norbert
>>>>>
>>>>> PS. shouldn`t the testsuite catch these bugs?
>>>>>
>>>>> [1]
>>>>> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=24e2b1cede1952d7d4411a3cafd25dd8593dab9f
>>>>> [2] https://llvm.org/bugs/show_bug.cgi?id=27310
>>>>> [3]
>>>>> https://github.com/llvm-mirror/compiler-rt/commit/827ea206c1078fc7c7da287984a7ba4563390589
>>>>> [4]
>>>>> https://github.com/llvm-mirror/compiler-rt/commit/570ee9dd7a6f90b0370a86535cbde6738d0ccf67
>>>>>
>>>>> 2016-10-31 21:43 GMT+01:00 Norbert Lange <nolange79 at gmail.com>:
>>>>>>
>>>>>> On Mon, 31 Oct 2016 08:38:21 +0100 Sylvestre Ledru
>>>>>> <sylvestre at debian.org> wrote:
>>>>>>>
>>>>>>> Le 31/10/2016 à 00:39, Norbert Lange a écrit :
>>>>>>>>
>>>>>>>> Package: clang-3.9
>>>>>>>> Version: 1:3.9-2
>>>>>>>> Severity: normal
>>>>>>>>
>>>>>>>> Dear Maintainer,
>>>>>>>>
>>>>>>>> The memory sanitizer is unusable as it segfaults during
>>>>>>>> initialization.
>>>>>>>> To reproduce:
>>>>>>>> echo 'int main() { return 0; }' >/tmp/test.c
>>>>>>>> clang -fsanitize=memory -o test test.c
>>>>>>>
>>>>>>> can you try with clang-3.9 instead?
>>>>>>
>>>>>> Same thing, output:
>>>>>>
>>>>>> $ clang-3.9 -fsanitize=memory -o test test.c -v
>>>>>> clang version 3.9.0-2 (tags/RELEASE_390/final)
>>>>>> Target: x86_64-pc-linux-gnu
>>>>>> Thread model: posix
>>>>>> InstalledDir: /usr/bin
>>>>>> Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6
>>>>>> Found candidate GCC installation:
>>>>>> /usr/bin/../lib/gcc/i686-linux-gnu/6.2.0
>>>>>> Found candidate GCC installation:
>>>>>> /usr/bin/../lib/gcc/x86_64-linux-gnu/5
>>>>>> Found candidate GCC installation:
>>>>>> /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
>>>>>> Found candidate GCC installation:
>>>>>> /usr/bin/../lib/gcc/x86_64-linux-gnu/6
>>>>>> Found candidate GCC installation:
>>>>>> /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
>>>>>> Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
>>>>>> Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.2.0
>>>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
>>>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
>>>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
>>>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
>>>>>> Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
>>>>>> Candidate multilib: .;@m64
>>>>>> Candidate multilib: 32;@m32
>>>>>> Candidate multilib: x32;@mx32
>>>>>> Selected multilib: .;@m64
>>>>>>   "/usr/lib/llvm-3.9/bin/clang" -cc1 -triple x86_64-pc-linux-gnu
>>>>>> -emit-obj -mrelax-all -disable-free -disable-llvm-verifier
>>>>>> -discard-value-names -main-file-name test.c -mrelocation-model static
>>>>>> -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
>>>>>> -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu
>>>>>> x86-64 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir
>>>>>> /usr/lib/llvm-3.9/bin/../lib/clang/3.9.0 -internal-isystem
>>>>>> /usr/local/include -internal-isystem
>>>>>> /usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/include
>>>>>> -internal-externc-isystem /usr/include/x86_64-linux-gnu
>>>>>> -internal-externc-isystem /include -internal-externc-isystem
>>>>>> /usr/include -fdebug-compilation-dir /tmp -ferror-limit 19
>>>>>> -fmessage-length 135 -fsanitize=memory
>>>>>>
>>>>>> -fsanitize-blacklist=/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/msan_blacklist.txt
>>>>>> -fno-assume-sane-operator-new -fobjc-runtime=gcc
>>>>>> -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-2d4d2c.o -x
>>>>>> c test.c
>>>>>> clang -cc1 version 3.9.0 based upon LLVM 3.9.0 default target
>>>>>> x86_64-pc-linux-gnu
>>>>>> ignoring nonexistent directory "/include"
>>>>>> #include "..." search starts here:
>>>>>> #include <...> search starts here:
>>>>>>   /usr/local/include
>>>>>>   /usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/include
>>>>>>   /usr/include/x86_64-linux-gnu
>>>>>>   /usr/include
>>>>>> End of search list.
>>>>>>   "/usr/bin/ld" --hash-style=both --eh-frame-hdr -m elf_x86_64
>>>>>> -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test
>>>>>>
>>>>>> /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0/../../../x86_64-linux-gnu/crt1.o
>>>>>>
>>>>>> /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0/../../../x86_64-linux-gnu/crti.o
>>>>>> /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0/crtbegin.o
>>>>>> -L/usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
>>>>>> -L/usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0/../../../x86_64-linux-gnu
>>>>>> -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
>>>>>> -L/usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0/../../..
>>>>>> -L/usr/lib/llvm-3.9/bin/../lib -L/lib -L/usr/lib -whole-archive
>>>>>>
>>>>>> /usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/lib/linux/libclang_rt.msan-x86_64.a
>>>>>> -no-whole-archive
>>>>>>
>>>>>> --dynamic-list=/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/lib/linux/libclang_rt.msan-x86_64.a.syms
>>>>>> /tmp/test-2d4d2c.o --no-as-needed -lpthread -lrt -lm -ldl -lgcc
>>>>>> --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
>>>>>> --no-as-needed /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0/crtend.o
>>>>>>
>>>>>> /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0/../../../x86_64-linux-gnu/crtn.o
>
>
>