search for: sanitizer_linux_libcdep

...on_tls.cc.tmp && /local/mnt/workspace/draco/out/release_stage2/projects/compiler-rt/lib/asan/lit_tests/Linux/Output/unpoison_tls.cc.tmp 2>&1 -- Exit Code: 1 Command Output (stdout): -- ==19600==AddressSanitizer CHECK failed: /local/mnt/workspace/draco/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc:244 "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0xf6111030, 0xf6111000) #0 0x8069d63 (/local/mnt/workspace/draco/out/release_stage2/projects/compiler-rt/lib/asan/lit_tests/Linux/Output/unpoison_tls.cc.tmp+0x8069d63) #1 0x806d30b (/local/mnt/workspace/draco/out/...

On Thu, May 30, 2013 at 10:05 PM, Greg Fitzgerald <garious at gmail.com> wrote: > The sanitizer common and asan that mention 'thread' are failing for me > this morning. How are your bots looking? Last good commit here was > 512c616cacf70ca029a2bf719a482b902f3687cd. > Hm, our bots seem to be green. Could you refer to guilty svn revision? > > > You could try

The sanitizer common and asan that mention 'thread' are failing for me this morning. How are your bots looking? Last good commit here was 512c616cacf70ca029a2bf719a482b902f3687cd. > You could try preprocessing your report with perl or sed to fix paths > to your binaries. It would be great to have an option for that in > asan_symbolize.py. > > As for addr2line, we just

As a temporary fix, you can replace this line in sanitizer_linux_libcdep.c: const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1216, 2304); with const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1168, 2304); The tests should pass after that. I need to figure out which ifdefs to put this under, so I might not be able to land the fix until Monday. On Fri, May...

...g+llvm does not like >>> -fsanitize=address on centos 6.4. By "like" I mean it asserts anytime a >>> thread is created. With errors like: >>> >>> ==18015==AddressSanitizer CHECK failed: >>> clang/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc:251 >>> "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0xf2f7d030, >>> 0xf2f7d000) >>> >>> If I use the llvm+clang 3.3 version it works properly. >>> - >>> This message is intended only for the addressee and may contai...

...-term. With the one change mentioned earlier (#include <stdint.h>), asan is working well for me when targeting either X86 Linux or ARM Android. -Greg On Fri, May 31, 2013 at 11:50 AM, Sergey Matveev <earthdok at google.com> wrote: > As a temporary fix, you can replace this line in sanitizer_linux_libcdep.c: > > const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1216, 2304); > > with > > const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1168, 2304); > > The tests should pass after that. I need to figure out which ifdefs to put > this under, so I might not be able to...

...s.com>> wrote: Hi, I noticed that the SVN version of clang+llvm does not like -fsanitize=address on centos 6.4. By "like" I mean it asserts anytime a thread is created. With errors like: ==18015==AddressSanitizer CHECK failed: clang/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc:251 "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0xf2f7d030, 0xf2f7d000) If I use the llvm+clang 3.3 version it works properly. - This message is intended only for the addressee and may contain information that is company confidential or privileged. Any technical data...

On Wed, Jul 13, 2016 at 04:48:51PM +0200, Sedat Dilek via llvm-dev wrote: > [ CCed all people who were involved in this thread ] > > Hi Tom, > > personally, I am interested to test the prebuilt-toolchains for > Ubuntu/xenial alias 16.04 LTS and Debian/Jessie v8.5.0 AMD64. > The available toolchains are incomplete and thus useless. > > Just as a fact: There is still no

...; I noticed that the SVN version of clang+llvm does not like > -fsanitize=address on centos 6.4. By "like" I mean it asserts anytime a > thread is created. With errors like: > > ==18015==AddressSanitizer CHECK failed: > clang/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc:251 > "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0xf2f7d030, > 0xf2f7d000) > > If I use the llvm+clang 3.3 version it works properly. > - > This message is intended only for the addressee and may contain > information that is company confidential...

...; I noticed that the SVN version of clang+llvm does not like > -fsanitize=address on centos 6.4. By "like" I mean it asserts anytime a > thread is created. With errors like: > > ==18015==AddressSanitizer CHECK failed: > clang/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc:251 > "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0xf2f7d030, > 0xf2f7d000) > > If I use the llvm+clang 3.3 version it works properly. > - > This message is intended only for the addressee and may contain > information that is company confidential...

...s.com>> wrote: Hi, I noticed that the SVN version of clang+llvm does not like -fsanitize=address on centos 6.4. By "like" I mean it asserts anytime a thread is created. With errors like: ==18015==AddressSanitizer CHECK failed: clang/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc:251 "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0xf2f7d030, 0xf2f7d000) If I use the llvm+clang 3.3 version it works properly. - This message is intended only for the addressee and may contain information that is company confidential or privileged. Any technical data...

> What version of glibc are you building with on x86? 2.11.1 for 64-bit x86 linux $ ldd --version ldd (Ubuntu EGLIBC 2.11.1-0ubuntu7.8) 2.11.1 On Fri, May 31, 2013 at 8:24 AM, Sergey Matveev <earthdok at google.com> wrote: > Those changes shouldn't affect ARM at all, since everything is under #if > defined(__i386__) || defined(__x86_64__). > > What version of glibc are

Those changes shouldn't affect ARM at all, since everything is under #if defined(__i386__) || defined(__x86_64__). What version of glibc are you building with on x86? On Fri, May 31, 2013 at 7:16 PM, Greg Fitzgerald <garious at gmail.com> wrote: > The failures happen on x86 Linux, Ubuntu Lucid. On ARM Android, my > example code segfaults, whereas before it worked. I