search for: matveev

...> wrote: > The failures happen on x86 Linux, Ubuntu Lucid. On ARM Android, my > example code segfaults, whereas before it worked. I wasn't planning to > debug that though since there are unit test failures on x86 Linux. > > Greg > > On May 31, 2013, at 2:37 AM, Sergey Matveev <earthdok at google.com> wrote: > > I'm confused - do those test failures happen on x86 Android? > > > On Fri, May 31, 2013 at 10:48 AM, Sergey Matveev <earthdok at google.com>wrote: > >> r182853 introduced an assumption about the size of thread descriptor in...

...31, 2013 at 8:48 PM, Greg Fitzgerald <garious at gmail.com> wrote: > > 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 you building with on x86? > > > > > > On Fri, May 31,...

> 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 you building with on x86? > > > On Fri, May 31, 2013 at 7:16 PM, Greg Fitzgerald <ga...

...l Monday. Okay, no worries, thanks for doing this. I've moved over to release_33 for the short-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); > > T...

I'm confused - do those test failures happen on x86 Android? On Fri, May 31, 2013 at 10:48 AM, Sergey Matveev <earthdok at google.com>wrote: > r182853 introduced an assumption about the size of thread descriptor in > glibc. On your system it's 48 bytes off, which is why the tests fail. What > version of libc are you using? > > (Repeating - my previous message got stuck in the mode...

The failures happen on x86 Linux, Ubuntu Lucid. On ARM Android, my example code segfaults, whereas before it worked. I wasn't planning to debug that though since there are unit test failures on x86 Linux. Greg On May 31, 2013, at 2:37 AM, Sergey Matveev <earthdok at google.com> wrote: > I'm confused - do those test failures happen on x86 Android? > > > On Fri, May 31, 2013 at 10:48 AM, Sergey Matveev <earthdok at google.com> wrote: >> r182853 introduced an assumption about the size of thread descriptor in glibc...

...Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. From: Kostya Serebryany [mailto:kcc at google.com] Sent: Monday, August 19, 2013 5:36 AM To: Sergey Matveev Cc: Sharma, Yogesh; llvmdev at cs.uiuc.edu Subject: Re: [cfe-dev] -fsanitize=address on centos 6.4 +llvmdev (llvm-dev does not exist) On Mon, Aug 19, 2013 at 12:58 PM, Sergey Matveev <earthdok at google.com<mailto:earthdok at google.com>> wrote: > First, could you please run the te...

...0000003b1d22ba1e 6 libc.so.6 0x0000003b1d22bae0 __assert_perror_fail + 0 7 i386-redhat-linux-gnu-clang++ 0x00000000006adb64 main + 8420 8 libc.so.6 0x0000003b1d21ecdd __libc_start_main + 253 9 i386-redhat-linux-gnu-clang++ 0x00000000006a5759 From: Sergey Matveev [mailto:earthdok at google.com] Sent: Monday, August 19, 2013 1:26 PM To: Sharma, Yogesh; Kostya Serebryany; llvmdev at cs.uiuc.edu List Subject: Re: [cfe-dev] -fsanitize=address on centos 6.4 +kcc, llvmdev I think your compiler-rt checkout is out of date, because r188635 is supposed to fix that...

...nc.**** > > This is free software; see the source for copying conditions. There is NO > **** > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > **** > > Written by Roland McGrath and Ulrich Drepper.**** > > ** ** > > *From:* Sergey Matveev [mailto:earthdok at google.com] > *Sent:* Monday, August 19, 2013 1:08 PM > *To:* Sharma, Yogesh > *Cc:* Kostya Serebryany; llvmdev at cs.uiuc.edu > > *Subject:* Re: [cfe-dev] -fsanitize=address on centos 6.4**** > > ** ** > > This looks like the output of "ld --ver...

+llvmdev (llvm-dev does not exist) On Mon, Aug 19, 2013 at 12:58 PM, Sergey Matveev <earthdok at google.com>wrote: > > First, could you please run the test with env.var. > ASAN_OPTIONS=verbosity=1 > > No need for that, actually, since this is a familiar issue. Sharma, could > you please paste the output of "ldd --version" here? > > Sergey &...

r182853 introduced an assumption about the size of thread descriptor in glibc. On your system it's 48 bytes off, which is why the tests fail. What version of libc are you using? (Repeating - my previous message got stuck in the moderation queue because the quoted text was too long.) -------------- next part -------------- An HTML attachment was scrubbed... URL:

...; *** > > the GNU General Public License version 3 or (at your option) a later > version.**** > > This program has absolutely no warranty.**** > > ** ** > > *From:* Kostya Serebryany [mailto:kcc at google.com] > *Sent:* Monday, August 19, 2013 5:36 AM > *To:* Sergey Matveev > *Cc:* Sharma, Yogesh; llvmdev at cs.uiuc.edu > *Subject:* Re: [cfe-dev] -fsanitize=address on centos 6.4**** > > ** ** > > +llvmdev (llvm-dev does not exist)**** > > ** ** > > On Mon, Aug 19, 2013 at 12:58 PM, Sergey Matveev <earthdok at google.com> > wrote:...

Hi all, Sometimes llvm::UpgradeDebugInfo <http://llvm.org/docs/doxygen/html/namespacellvm.html#ad3c29183c5faa7f5a352807af8aca268> drops debug info which is pretty compatible with recent llvm version ( http://stackoverflow.com/questions/27023713/missing-debug-metadata-in-llvm-after-xcode-update ) and sometimes it drops something really outdated, but acceptable for me. In both cases I want to

+Sergey Matveev On Wed, Jul 10, 2013 at 2:00 AM, Andy Jost <Andrew.Jost at synopsys.com> wrote: > Ok, after familiarizing myself with clone it appears to me this is a bug > in compiler-rt.**** > > ** ** > > From the clone man page:**** > > ** ** > > In Linux 2.4 and earlier,...

...mbinedAllocator<PrimaryAllocator, AllocatorCache, SecondaryAllocator> Allocator; -static THREADLOCAL AllocatorCache cache; +static /*THREADLOCAL*/ AllocatorCache cache; static Allocator allocator; static int inited = 0; On Fri, May 24, 2013 at 6:10 AM, Sergey Matveev <earthdok at google.com> wrote: > I blame this line in lsan/lit_tests/lit.cfg: > > # Setup attributes common for all compiler-rt projects. > > > compiler_rt_lit_cfg = os.path.join(llvm_src_root, "projects", > "compiler-rt", > >...

...e, > SecondaryAllocator> Allocator; > > -static THREADLOCAL AllocatorCache cache; > +static /*THREADLOCAL*/ AllocatorCache cache; > static Allocator allocator; > > static int inited = 0; > > > > On Fri, May 24, 2013 at 6:10 AM, Sergey Matveev <earthdok at google.com> wrote: >> >> I blame this line in lsan/lit_tests/lit.cfg: >> >> # Setup attributes common for all compiler-rt projects. >> compiler_rt_lit_cfg = os.path.join(llvm_src_root, "projects", >> "compiler-rt", >>...

I get leaks from a system library: ==16272==ERROR: LeakSanitizer: detected memory leaks Direct leak of 148 byte(s) in 2 object(s) allocated from: #0 0x4a3172 in __interceptor_malloc .../build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3 #1 0x7f575d8df1fe in wcsdup (/lib64/libedit.so.0+0x1c1fe) I don't think I can fix this... ;] -Chandler -------------- next part

...; > -static THREADLOCAL AllocatorCache cache; >> > +static /*THREADLOCAL*/ AllocatorCache cache; >> > static Allocator allocator; >> > >> > static int inited = 0; >> > >> > >> > >> > On Fri, May 24, 2013 at 6:10 AM, Sergey Matveev <earthdok at google.com> >> wrote: >> >> >> >> I blame this line in lsan/lit_tests/lit.cfg: >> >> >> >> # Setup attributes common for all compiler-rt projects. >> >> compiler_rt_lit_cfg = os.path.join(llvm_src_root, "proje...

I blame this line in lsan/lit_tests/lit.cfg: # Setup attributes common for all compiler-rt projects. compiler_rt_lit_cfg = os.path.join(llvm_src_root, "projects", "compiler-rt", "lib", "lit.common.cfg") On Fri, May 24, 2013 at 2:53 PM, Alexey Samsonov <samsonov at google.com>wrote: > > On Fri, May 24,

...tor> Allocator; > > > > -static THREADLOCAL AllocatorCache cache; > > +static /*THREADLOCAL*/ AllocatorCache cache; > > static Allocator allocator; > > > > static int inited = 0; > > > > > > > > On Fri, May 24, 2013 at 6:10 AM, Sergey Matveev <earthdok at google.com> > wrote: > >> > >> I blame this line in lsan/lit_tests/lit.cfg: > >> > >> # Setup attributes common for all compiler-rt projects. > >> compiler_rt_lit_cfg = os.path.join(llvm_src_root, "projects", > >>...