search for: mz_free

...AddressSanitizer :: use-after-free.cc > This failure seems to be due to adding ALWAYS_INLINE to 'free_common' in r158885. I think fixing the stack trace checks in use-after-free.cc will do: - // CHECK-Darwin: {{ #0 0x.* in .*free_common.*}} - // CHECK-Darwin: {{ #1 0x.* in .*mz_free.*}} + // CHECK-Darwin: {{ #0 0x.* in .*mz_free.*}} // We override free() on Darwin, thus no malloc_zone_free - // CHECK-Darwin: {{ #2 0x.* in _?wrap_free}} - // CHECK-Darwin: {{ #3 0x.* in _?main .*use-after-free.cc:21}} + // CHECK-Darwin: {{ #1 0x.* in _?wrap_free}} + // CHECK-...

I am building LLVM on OS X 10.7.5 with cmake. Under this configuration some ASan and UBSan tests are failing: $ make check-ubsan … ******************** Testing Time: 2.36s ******************** Failing Tests (11): UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp UndefinedBehaviorSanitizer :: Integer/div-zero.cpp

...ee.cc >> > > This failure seems to be due to adding ALWAYS_INLINE to 'free_common' in r158885. > I think fixing the stack trace checks in use-after-free.cc will do: > > - // CHECK-Darwin: {{ #0 0x.* in .*free_common.*}} > - // CHECK-Darwin: {{ #1 0x.* in .*mz_free.*}} > + // CHECK-Darwin: {{ #0 0x.* in .*mz_free.*}} > // We override free() on Darwin, thus no malloc_zone_free > - // CHECK-Darwin: {{ #2 0x.* in _?wrap_free}} > - // CHECK-Darwin: {{ #3 0x.* in _?main .*use-after-free.cc:21}} > + // CHECK-Darwin: {{ #1 0x.* in _?...

...t; This failure seems to be due to adding ALWAYS_INLINE to 'free_common' in > r158885. > > I think fixing the stack trace checks in use-after-free.cc will do: > > > > - // CHECK-Darwin: {{ #0 0x.* in .*free_common.*}} > > - // CHECK-Darwin: {{ #1 0x.* in .*mz_free.*}} > > + // CHECK-Darwin: {{ #0 0x.* in .*mz_free.*}} > > // We override free() on Darwin, thus no malloc_zone_free > > - // CHECK-Darwin: {{ #2 0x.* in _?wrap_free}} > > - // CHECK-Darwin: {{ #3 0x.* in _?main .*use-after-free.cc:21}} > > + // CHECK-Da...

...sts/use-after-free.cc:22:0 #1 0x7fff8bd827e0 in start (in libdyld.dylib) + 0 #2 0x0 0x00010c958fc5 is located 5 bytes inside of 10-byte region [0x00010c958fc0,0x00010c958fca) freed by thread T0 here: #0 0x10a67e6a8 in free_common _asan_rtl_:5 #1 0x10a67e6a8 in (anonymous namespace)::mz_free(_malloc_zone_t*, void*) _asan_rtl_:0 #2 0x10a67dd22 in _wrap_free _asan_rtl_:7 #3 0x10a675bd7 in _main /sw/src/fink.build/llvm32-3.2-0/llvm-3.2/projects/compiler-unsigned short restrict/lib/asan/lit_tests/use-after-free.cc:21:0 #4 0x7fff8bd827e0 in start (in libdyld.dylib) + 0 #4 0x...

Hi, Jack! On Fri, Nov 2, 2012 at 6:18 PM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > Nick, > Have you noticed that llvm/clang svn produces the following linker > warnings on > 'make check-all'? > > Linking CXX executable Debug/AsanTest > ld: warning: direct access in > llvm::convertible_fwd_ostream::~convertible_fwd_ostream() to global weak >

Nick, Have you noticed that llvm/clang svn produces the following linker warnings on 'make check-all'? Linking CXX executable Debug/AsanTest ld: warning: direct access in llvm::convertible_fwd_ostream::~convertible_fwd_ostream() to global weak symbol vtable for llvm::convertible_fwd_ostream means the weak symbol cannot be overridden at runtime. This was likely caused by different