assert on destroy (inside of release function) non-orphan entity about entt

[skypjack]

Well, let me know if I can help hands-on with the code then. I'm more than willing in case. 🙂👍

[skypjack]

maybe that should assert already?

I think the upstream version already contains these asserts for the next release. Someone popped up with the exact same request less than a month ago. 🙂

[skypjack]

I cannot say what's happening without a repro. However, do you have listeners on components? As an example, a listener that gets triggered when a component is erased.

[immerhart]

Thanks for the idea, but no :/
We use entt::dispatcher for some event stuff, but nothing related to entity deletion, as far as I can tell.
The code can't be shared unfortunately...

After further analysis:

    version_type destroy(const entity_type entt, const version_type version) {
        for(size_type pos = pools.size(); pos; --pos) {
            pools.begin()[pos - 1u].second->remove(entt);
        }

        return release(entt, version);
    }

calls the remove func:

    bool remove(const entity_type entt) {
        return contains(entt) && (erase(entt), true);
    }

and the contains returns false here, which is opaque, as this is the first call to destroy for this entity.
The returned entity from the registry is saved to a local variable inside a member function. This variable is passed in by value capture to a lambda and the lambda does the destroy call.
Maybe there is something wrong with the saving/passing of the entity? But not sure what could be wrong there...
(also, it always happens with entt::to_integral == 4294967296)

[immerhart]

good enough XD

[skypjack]

good enough XD

It is not. You're probably hiding an UB with this guard.

[immerhart]

Ofcs not, but as you pointed out, without the code, no one will be able to help, so this issue does not make much sense here.

[immerhart]

Thank you very much for the offer, much appreciated!
But we actually found the issue this evening (still not sure why it caused the assert, though; but after the fix we aren't facing the crash anymore).
It's actually quite embarrassing (even more, because it was me refactoring this, but sometimes stuff just goes wrong XD). In one class we had an uninitialized entt::entity member variable. At some event trigger, the class was assigning a component to that entity over emplace_or_replace, which works just fine (maybe that should assert already?).
And somehow this leads to the assert mentioned at the top, no clue why, but the error was ofc adding the component to an uninitialized entt::entity, which maybe messes up some internal state...