fegennari

Okay, I think I understand what the problem is. The failure happens inside raw_hash_set::resize(). capacity_ is set to new_capacity on phmap.h line 1925. Then initialize_slots() is called. The call to...

I tried to set capacity_ inside initialize_slots(), but that still seg faults. I think many of the member functions use that capacity_ field so I'm not sure where this should...

I think my capacity_ change fixed that failure, and I'm seeing a different failure mode. I'm just running this in a loop trying to make it fail because it seems...

I think the new failure is the same type of problem. prepare_insert() calls set_ctrl() on the element to "enable" it before the data has been copied. Then when the allocation...

Thanks! That appears to have fixed the original failure, but I still see the failure related to prepare_insert(). I'm less confident I understand that problem. See my previous two comments.

Thanks for trying but you're right, it doesn't work: eclair: ../src/parallel_hashmap/phmap.h:2143: void phmap::priv::raw_hash_set::emplace_at(size_t, Args&& ...) [with Args = {const std::piecewise_construct_t&, std::tuple, std::tuple}; Policy = phmap::priv::FlatHashMapPolicy; Hash = phmap::Hash; Eq =...

I found one somewhat hacky way of fixing it. I replaced the construct() call in emplace_at() with a try/catch block like this: try { PolicyTraits::construct(&alloc_ref(), slots_ + i, std::forward(args)...); }...

Yes my solution isn't the best one for all users. Our codebase uses exceptions everywhere already, which is why I'm okay with this. I wanted to put the fix directly...

Great, thanks! I haven't run into that problem since I posted the original issue, so it doesn't seem too common. I'll see if I can find my original test case...

I'm not sure what I currently have the code doing. I'll check when I'm at work on Monday. Thanks.