https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127675
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2026-09-30
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #0)
> *********************************/home/jwakely/gcc/14/include/c++/14.4.1/ext/
> pb_ds/detail/ov_tree_map_/erase_fn_imps.hpp:179:
> In function:
> void gnu_pbds::detail::ov_tree_map<Key, Mapped, Cmp_Fn,
> Node_And_It_Traits, _Alloc>::assert_valid(const char*, int) const [with
> Key = gnu_pbds::test::basic_type; Mapped = gnu_pbds::test::basic_type;
> Cmp_Fn = std::less<gnu_pbds::test::basic_type>; Node_And_It_Traits =
> gnu_pbds::detail::tree_traits<gnu_pbds::test::basic_type,
> gnu_pbds::test::basic_type, std::less<gnu_pbds::test::basic_type>,
> gnu_pbds::tree_order_statistics_node_update, gnu_pbds::ov_tree_tag,
> gnu_cxx::throw_allocator_random<gnu_pbds::test::basic_type> >; _Alloc =
> gnu_cxx::throw_allocator_random<gnu_pbds::test::basic_type>]
>
> Error: m_a_values == 0 && m_end_it == 0 && m_size == 0 assertion from
> /home/jwakely/gcc/14/include/c++/14.4.1/ext/pb_ds/detail/ov_tree_map_/
> debug_fn_imps.hpp
> :51.
> Aborted (core dumped) ./a.out
This one turns out to be trivial to reproduce:
#include <ext/pb_ds/assoc_container.hpp>
int main()
{
using namespace __gnu_pbds;
tree<int, int, std::less<int>, ov_tree_tag> m;
m[1] = 1;
m.erase(m.begin());
}
The assertion in ov_tree_map::assert_valid checks this:
if (m_a_values == 0 || m_end_it == 0 || m_size == 0)
PB_DS_DEBUG_VERIFY(m_a_values == 0 && m_end_it == 0 && m_size == 0);
i.e. if any of those values is not set, they're all not set.
But that's simply not true. In ov_tree_map::erase_imp(It) when the initial size
is one and we remove the last element (as in the reproducer above), we have
m_size == 0 but m_a_values points to a non-null allocated pointer.
I don't think this assertion has every been correct for this container type.
