Hm, that bug has been closed as resolved but I still see the problem: $ clang --version clang version 3.8.0 (trunk 250848) (llvm/trunk 250846) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin configure:4042: ./conftest FATAL: Code 0x5615faea43f0 is out of application range. Non-PIE build? FATAL: MemorySanitizer can not mmap the shadow memory. FATAL: Make sure to compile with -fPIE and to link with -pie. FATAL: Disabling ASLR is known to cause this error. FATAL: If running under GDB, try 'set disable-randomization off'. ==14645==Process memory map follows: 0x5615fae87000-0x5615faf26000 /home/stark/src/pg/postgresql-master/conftest 0x5615fb126000-0x5615fb12a000 /home/stark/src/pg/postgresql-master/conftest 0x5615fb12a000-0x5615fd59d000 0x7f86a64a3000-0x7f86a67f5000 0x7f86a67f5000-0x7f86a6994000 /lib/x86_64-linux-gnu/libc-2.19.so 0x7f86a6994000-0x7f86a6b94000 /lib/x86_64-linux-gnu/libc-2.19.so 0x7f86a6b94000-0x7f86a6b98000 /lib/x86_64-linux-gnu/libc-2.19.so 0x7f86a6b98000-0x7f86a6b9a000 /lib/x86_64-linux-gnu/libc-2.19.so 0x7f86a6b9a000-0x7f86a6b9e000 0x7f86a6b9e000-0x7f86a6bb4000 /lib/x86_64-linux-gnu/libgcc_s.so.1 0x7f86a6bb4000-0x7f86a6db3000 /lib/x86_64-linux-gnu/libgcc_s.so.1 0x7f86a6db3000-0x7f86a6db4000 /lib/x86_64-linux-gnu/libgcc_s.so.1 0x7f86a6db4000-0x7f86a6db7000 /lib/x86_64-linux-gnu/libdl-2.19.so 0x7f86a6db7000-0x7f86a6fb6000 /lib/x86_64-linux-gnu/libdl-2.19.so 0x7f86a6fb6000-0x7f86a6fb7000 /lib/x86_64-linux-gnu/libdl-2.19.so 0x7f86a6fb7000-0x7f86a6fb8000 /lib/x86_64-linux-gnu/libdl-2.19.so 0x7f86a6fb8000-0x7f86a70b8000 /lib/x86_64-linux-gnu/libm-2.19.so 0x7f86a70b8000-0x7f86a72b7000 /lib/x86_64-linux-gnu/libm-2.19.so 0x7f86a72b7000-0x7f86a72b8000 /lib/x86_64-linux-gnu/libm-2.19.so 0x7f86a72b8000-0x7f86a72b9000 /lib/x86_64-linux-gnu/libm-2.19.so 0x7f86a72b9000-0x7f86a72c0000 /lib/x86_64-linux-gnu/librt-2.19.so 0x7f86a72c0000-0x7f86a74bf000 /lib/x86_64-linux-gnu/librt-2.19.so 0x7f86a74bf000-0x7f86a74c0000 /lib/x86_64-linux-gnu/librt-2.19.so 0x7f86a74c0000-0x7f86a74c1000 /lib/x86_64-linux-gnu/librt-2.19.so 0x7f86a74c1000-0x7f86a74d9000 /lib/x86_64-linux-gnu/libpthread-2.19.so 0x7f86a74d9000-0x7f86a76d8000 /lib/x86_64-linux-gnu/libpthread-2.19.so 0x7f86a76d8000-0x7f86a76d9000 /lib/x86_64-linux-gnu/libpthread-2.19.so 0x7f86a76d9000-0x7f86a76da000 /lib/x86_64-linux-gnu/libpthread-2.19.so 0x7f86a76da000-0x7f86a76de000 0x7f86a76de000-0x7f86a76fe000 /lib/x86_64-linux-gnu/ld-2.19.so 0x7f86a78d7000-0x7f86a78dc000 0x7f86a78f2000-0x7f86a78fe000 0x7f86a78fe000-0x7f86a78ff000 /lib/x86_64-linux-gnu/ld-2.19.so 0x7f86a78ff000-0x7f86a7900000 /lib/x86_64-linux-gnu/ld-2.19.so 0x7f86a7900000-0x7f86a7901000 0x7fff98977000-0x7fff98998000 [stack] 0x7fff989b2000-0x7fff989b4000 [vvar] 0x7fff989b4000-0x7fff989b6000 [vdso] 0xffffffffff600000-0xffffffffff601000 [vsyscall] ==14645==End of process memory map. On Mon, Sep 14, 2015 at 9:46 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com> wrote:> Yes, the kernel is too new. > This bug has a patch set that's compatible with the new kernel and > does not even require -pie: > https://llvm.org/bugs/show_bug.cgi?id=24155 > It breaks MSan ABI though, so we can not apply it upstream yet. > > > On Sat, Sep 12, 2015 at 3:31 PM, Kostya Serebryany via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> clang revision is good, but the kernel is probably too new. >> Evgenii can comment on that. >> >> On Sat, Sep 12, 2015 at 3:23 PM, Greg Stark <stark at mit.edu> wrote: >>> >>> On Sat, Sep 12, 2015 at 11:22 PM, Greg Stark <stark at mit.edu> wrote: >>> > Checked out a few days ago. It looks like r246697. I suppose I could >>> > try updating and rebuilding. >>> >>> Sorry, svn log in the tools/clang directory shows r246702. >>> >>> >>> -- >>> greg >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>-- greg
Kostya Serebryany via llvm-dev
2015-Oct-20 21:53 UTC
[llvm-dev] Some feedback on Libfuzzer
Can you open a separate bug with exact repro instructions? On Tue, Oct 20, 2015 at 2:47 PM, Greg Stark <stark at mit.edu> wrote:> Hm, that bug has been closed as resolved but I still see the problem: > > $ clang --version > clang version 3.8.0 (trunk 250848) (llvm/trunk 250846) > Target: x86_64-unknown-linux-gnu > Thread model: posix > InstalledDir: /usr/local/bin > > > configure:4042: ./conftest > FATAL: Code 0x5615faea43f0 is out of application range. Non-PIE build? > FATAL: MemorySanitizer can not mmap the shadow memory. > FATAL: Make sure to compile with -fPIE and to link with -pie. > FATAL: Disabling ASLR is known to cause this error. > FATAL: If running under GDB, try 'set disable-randomization off'. > ==14645==Process memory map follows: > 0x5615fae87000-0x5615faf26000 /home/stark/src/pg/postgresql-master/conftest > 0x5615fb126000-0x5615fb12a000 /home/stark/src/pg/postgresql-master/conftest > 0x5615fb12a000-0x5615fd59d000 > 0x7f86a64a3000-0x7f86a67f5000 > 0x7f86a67f5000-0x7f86a6994000 /lib/x86_64-linux-gnu/libc-2.19.so > 0x7f86a6994000-0x7f86a6b94000 /lib/x86_64-linux-gnu/libc-2.19.so > 0x7f86a6b94000-0x7f86a6b98000 /lib/x86_64-linux-gnu/libc-2.19.so > 0x7f86a6b98000-0x7f86a6b9a000 /lib/x86_64-linux-gnu/libc-2.19.so > 0x7f86a6b9a000-0x7f86a6b9e000 > 0x7f86a6b9e000-0x7f86a6bb4000 /lib/x86_64-linux-gnu/libgcc_s.so.1 > 0x7f86a6bb4000-0x7f86a6db3000 /lib/x86_64-linux-gnu/libgcc_s.so.1 > 0x7f86a6db3000-0x7f86a6db4000 /lib/x86_64-linux-gnu/libgcc_s.so.1 > 0x7f86a6db4000-0x7f86a6db7000 /lib/x86_64-linux-gnu/libdl-2.19.so > 0x7f86a6db7000-0x7f86a6fb6000 /lib/x86_64-linux-gnu/libdl-2.19.so > 0x7f86a6fb6000-0x7f86a6fb7000 /lib/x86_64-linux-gnu/libdl-2.19.so > 0x7f86a6fb7000-0x7f86a6fb8000 /lib/x86_64-linux-gnu/libdl-2.19.so > 0x7f86a6fb8000-0x7f86a70b8000 /lib/x86_64-linux-gnu/libm-2.19.so > 0x7f86a70b8000-0x7f86a72b7000 /lib/x86_64-linux-gnu/libm-2.19.so > 0x7f86a72b7000-0x7f86a72b8000 /lib/x86_64-linux-gnu/libm-2.19.so > 0x7f86a72b8000-0x7f86a72b9000 /lib/x86_64-linux-gnu/libm-2.19.so > 0x7f86a72b9000-0x7f86a72c0000 /lib/x86_64-linux-gnu/librt-2.19.so > 0x7f86a72c0000-0x7f86a74bf000 /lib/x86_64-linux-gnu/librt-2.19.so > 0x7f86a74bf000-0x7f86a74c0000 /lib/x86_64-linux-gnu/librt-2.19.so > 0x7f86a74c0000-0x7f86a74c1000 /lib/x86_64-linux-gnu/librt-2.19.so > 0x7f86a74c1000-0x7f86a74d9000 /lib/x86_64-linux-gnu/libpthread-2.19.so > 0x7f86a74d9000-0x7f86a76d8000 /lib/x86_64-linux-gnu/libpthread-2.19.so > 0x7f86a76d8000-0x7f86a76d9000 /lib/x86_64-linux-gnu/libpthread-2.19.so > 0x7f86a76d9000-0x7f86a76da000 /lib/x86_64-linux-gnu/libpthread-2.19.so > 0x7f86a76da000-0x7f86a76de000 > 0x7f86a76de000-0x7f86a76fe000 /lib/x86_64-linux-gnu/ld-2.19.so > 0x7f86a78d7000-0x7f86a78dc000 > 0x7f86a78f2000-0x7f86a78fe000 > 0x7f86a78fe000-0x7f86a78ff000 /lib/x86_64-linux-gnu/ld-2.19.so > 0x7f86a78ff000-0x7f86a7900000 /lib/x86_64-linux-gnu/ld-2.19.so > 0x7f86a7900000-0x7f86a7901000 > 0x7fff98977000-0x7fff98998000 [stack] > 0x7fff989b2000-0x7fff989b4000 [vvar] > 0x7fff989b4000-0x7fff989b6000 [vdso] > 0xffffffffff600000-0xffffffffff601000 [vsyscall] > ==14645==End of process memory map. > > On Mon, Sep 14, 2015 at 9:46 PM, Evgenii Stepanov > <eugeni.stepanov at gmail.com> wrote: > > Yes, the kernel is too new. > > This bug has a patch set that's compatible with the new kernel and > > does not even require -pie: > > https://llvm.org/bugs/show_bug.cgi?id=24155 > > It breaks MSan ABI though, so we can not apply it upstream yet. > > > > > > On Sat, Sep 12, 2015 at 3:31 PM, Kostya Serebryany via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> clang revision is good, but the kernel is probably too new. > >> Evgenii can comment on that. > >> > >> On Sat, Sep 12, 2015 at 3:23 PM, Greg Stark <stark at mit.edu> wrote: > >>> > >>> On Sat, Sep 12, 2015 at 11:22 PM, Greg Stark <stark at mit.edu> wrote: > >>> > Checked out a few days ago. It looks like r246697. I suppose I could > >>> > try updating and rebuilding. > >>> > >>> Sorry, svn log in the tools/clang directory shows r246702. > >>> > >>> > >>> -- > >>> greg > >> > >> > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > > > > -- > greg >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151020/e844a786/attachment.html>
On Tue, Oct 20, 2015 at 10:53 PM, Kostya Serebryany <kcc at google.com> wrote:> Can you open a separate bug with exact repro instructions?Well the bug tracker seems to require an account. But in any case I don't see anything specific to reproduce. I did an svn update of llvm and clang and built and installed (I even tried make clean and removed the old install but it didn't change anything). Then any program I compile with -fsanitize=memory behaves just like it did before the patch: $ uname -a Linux pixel 4.2.0-trunk-amd64 #1 SMP Debian 4.2-1~exp1 (2015-08-31) x86_64 GNU/Linux $ cat foo.c int main(int argc, char *argv[], char *env[]) { return 0; } $ clang -fPIE -pie -fsanitize=memory foo.c $ ./a.out FATAL: Code 0x562988448390 is out of application range. Non-PIE build? FATAL: MemorySanitizer can not mmap the shadow memory. FATAL: Make sure to compile with -fPIE and to link with -pie. FATAL: Disabling ASLR is known to cause this error. FATAL: If running under GDB, try 'set disable-randomization off'. ==3120==Process memory map follows: 0x56298842b000-0x5629884ca000 /tmp/a.out 0x5629886ca000-0x5629886ce000 /tmp/a.out 0x5629886ce000-0x56298ab41000 0x7f387d560000-0x7f387d8b2000 ... -- greg