search for: sizeclassallocator64

...ot;word"... Reading symbols from a...done. (gdb) run Starting program: /home/wink/foss/llvm.3.9.0/test-msan/a [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. __sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback>::AllocateBatch ( this=this at entry=0x21289a0 <__msan::allocator>, stat=stat at entry=0x2128970 <__msan::fallback_allocator_cache+109392>, c=c at entry=0x...

First off, thanks -- this is a pretty great library and it feels like I'm learning a lot. I'm getting some more experience with libfuzzer and finding that I have a couple of questions: - How does libfuzzer decide to write a new test file? What distinguishes this one from all the other cases for which new test inputs were not written? Must be something about the path taken through the

...__sanitizer::BlockingMutex::Lock (this=this at entry=0x640000001290) at /home/brian/tmp/testing/llvm_src/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:471 #2 0x0000000000447899 in GenericScopedLock (mu=mu at entry=0x640000001290, this=<synthetic pointer>) #3 __sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __asan::AsanMapUnmapCallback>::PopulateFreeList ( #4 0x0000000000447ff8 in __sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul...

.... Reading symbols from eventfd...done. (gdb) run Starting program: /home/wink/foss/llvm.3.9.0/test-eventfd/eventfd [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. __sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback>::AllocateBatch ( this=this at entry=0x212c9a0 <__msan::allocator>, stat=stat at entry=0x212c970 <__msan::fallback_allocator_cache+109392>, c=c at entry=0x...

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

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