On Thu, 19 Jul 2018 at 23:26, Paul Smith wrote:
>
> In our Valgrind testing since the change we've seen thousands and
> thousands of new errors about mismatched free / delete / delete [].
> All of them appear to be emitted from STL allocations. For example:
>
> ==30514== Mismatched free() / delete / delete []
> ==30514== at 0x4C30C9B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==30514== by 0x5E617B: deallocate (new_allocator.h:125)
> ==30514== by 0x5E617B: deallocate (alloc_traits.h:462)
> ==30514== by 0x5E617B: _M_deallocate (stl_vector.h:304)
> ==30514== by 0x5E617B: void std::vector<...
> ...
> ==30514== Address 0x80d37c0 is 0 bytes inside a block of size 8 alloc'd
> ==30514== at 0x4C3017F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==30514== by 0x5E60DB: allocate (new_allocator.h:111)
> ==30514== by 0x5E60DB: allocate (alloc_traits.h:436)
> ==30514== by 0x5E60DB: _M_allocate (stl_vector.h:296)
> ==30514== by 0x5E60DB: void std::vector<...
> ...
>
> I can't explain why the deallocate() in new_allocator.h:125:
>
> void
> deallocate(pointer __p, size_type)
> {
> #if __cpp_aligned_new
> if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__)
> {
> ::operator delete(__p, std::align_val_t(alignof(_Tp)));
> return;
> }
> #endif
> ::operator delete(__p);
> }
>
> should be interpreted as invoking valgrind's free(), while the
> allocate() in that same file at line 111:
>
> pointer
> allocate(size_type __n, const void* = static_cast<const void*>(0))
> {
> if (__n > this->max_size())
> std::__throw_bad_alloc();
>
> #if __cpp_aligned_new
> if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__)
> {
> std::align_val_t __al = std::align_val_t(alignof(_Tp));
> return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp), __al));
> }
> #endif
> return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
> }
>
> is seen as invoking valgrind's operator new implementation rather than
> malloc.
Looks like a valgrind bug.
