search for: sanitizer_allocator

...atch ( this=this at entry=0x212c9a0 <__msan::allocator>, stat=stat at entry=0x212c970 <__msan::fallback_allocator_cache+109392>, c=c at entry=0x2111e20 <__msan::fallback_allocator_cache>, class_id=class_id at entry=6) at ../projects/compiler-rt/lib/msan/../sanitizer_common/sanitizer_allocator.h:357 357 Batch *b = region->free_list.Pop(); (gdb) bt #0 __sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback>::AllocateBatch ( this=this at entry=0x212c9a0 <__msan::allocator...

Hello, We've had a build that hit the following assert: AddressSanitizer CHECK failed: /var/lib/jenkins/jenkins/workspace/fst-clang/local/src/llvm/llvm-3.9.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1078 "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) Increasing the limit and recompiling seems like the obvious workaround, but I'm wondering if i have better options than that. Any thoughts? Thank you, Frederik

...atch ( this=this at entry=0x21289a0 <__msan::allocator>, stat=stat at entry=0x2128970 <__msan::fallback_allocator_cache+109392>, c=c at entry=0x210de20 <__msan::fallback_allocator_cache>, class_id=class_id at entry=5) at ../projects/compiler-rt/lib/msan/../sanitizer_common/sanitizer_allocator.h:357 357 Batch *b = region->free_list.Pop(); (gdb) bt #0 __sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback>::AllocateBatch ( this=this at entry=0x21289a0 <__msan::allocator...

I've "successfully" built 3.9.0 release but when I run "ninja check-all" I got 208 Unexpected failures: Expected Passes : 33997 Expected Failures : 198 Unsupported Tests : 685 Unexpected Failures: 208 Below is the log I captured running "time ninja check-all | tee ninja-check-all.txt" https://drive.google.com/open?id=0B-KTY7zi7eZHU2hGYTRtd01QZjA

...ev < llvm-dev at lists.llvm.org> wrote: > Hello, > > We've had a build that hit the following assert: > AddressSanitizer CHECK failed: > /var/lib/jenkins/jenkins/workspace/fst-clang/local/src/ > llvm/llvm-3.9.0.src/projects/compiler-rt/lib/asan/../ > sanitizer_common/sanitizer_allocator.h:1078 > "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) > > Increasing the limit and recompiling seems like the obvious > workaround, but I'm wondering if i have better options than that. Any > thoughts? > > Thank you, > Frederik > _____________________...

....llvm.org> wrote: >> >> Hello, >> >> We've had a build that hit the following assert: >> AddressSanitizer CHECK failed: >> >> /var/lib/jenkins/jenkins/workspace/fst-clang/local/src/llvm/llvm-3.9.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1078 >> "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) >> >> Increasing the limit and recompiling seems like the obvious >> workaround, but I'm wondering if i have better options than that. Any >> thoughts? >> >> Thank you, >> Fre...

...; Hello, > >> > >> We've had a build that hit the following assert: > >> AddressSanitizer CHECK failed: > >> > >> /var/lib/jenkins/jenkins/workspace/fst-clang/local/src/ > llvm/llvm-3.9.0.src/projects/compiler-rt/lib/asan/../ > sanitizer_common/sanitizer_allocator.h:1078 > >> "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) > >> > >> Increasing the limit and recompiling seems like the obvious > >> workaround, but I'm wondering if i have better options than that. Any > >> thoughts? > >> &g...

...CHECK failed: /local/mnt/workspace/draco/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc:244 "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0xf0be3030, 0xf0be3000) ==21625==AddressSanitizer CHECK failed: /local/mnt/workspace/draco/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:126 "((allocated_end_ - allocated_current_ >= (sptr)size)) != (0)" (0x0, 0x0) #0 0x806c0e3 (/local/mnt/workspace/draco/out/release_stage2/projects/compiler-rt/lib/asan/tests/Asan-i386-Test+0x806c0e3) ==21625==AddressSanitizer CHECK failed: /local/mnt/workspace/draco/compiler-rt/...

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