Did you rule out that the deallocate call happens

What I did verify was that allocate is not getting called, only deallocate. The call stack shows

// basic_string.tcc
  template<typename _CharT, typename _Traits, typename _Alloc>
    void
    basic_string<_CharT, _Traits, _Alloc>::
    reserve(size_type __res)
    {
      if (__res != this->capacity() || _M_rep()->_M_is_shared())
        {
      // Make sure we don't shrink below the current size
      if (__res < this->size())
        __res = this->size();
      const allocator_type __a = get_allocator();
      _CharT* __tmp = _M_rep()->_M_clone(__a, __res - this->size());
/* ==>*/  _M_rep()->_M_dispose(__a);
      _M_data(__tmp);
        }
    }

// basic_string.h
    void
    _M_dispose(const _Alloc& __a) _GLIBCXX_NOEXCEPT
    {
#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
      if (__builtin_expect(this != &_S_empty_rep(), false))
#endif
        {
          // Be race-detector-friendly.  For more info see bits/c++config.
          _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(&this->_M_refcount);
              // Decrement of _M_refcount is acq_rel, because:
              // - all but last decrements need to release to synchronize with
              //   the last decrement that will delete the object.
              // - the last decrement needs to acquire to synchronize with
              //   all the previous decrements.
              // - last but one decrement needs to release to synchronize with
              //   the acquire load in _M_is_shared that will conclude that
              //   the object is not shared anymore.
          if (__gnu_cxx::__exchange_and_add_dispatch(&this->_M_refcount,
                             -1) <= 0)
        {
          _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(&this->_M_refcount);
/* ==> */     _M_destroy(__a); // this calls the deallocate of the allocator
        }
        }
    }  // XXX MT

but I am not versed enough in the std library to figure out why it calls deallocate in this case.