Skip to content
Commit 5ee8b288 authored by Harald Sitter's avatar Harald Sitter 🍌
Browse files

reliably drop component pools

previously this was extra wrong.

we had connected the componentPool (sender) to the engine (receiver),
but the engine is the parent of the componentPool, so the engine was
already disconnected by the time componentPool emitted destroyed and as
such never receive the destroyed signal, never remove the pool entry,
and then eventually crash if that engine address got reused

fix this aggressively since technically either the key or the
value may get destroyed and that'd constitute removal from the pool. one
shouldn't really be deleted without the other, but let's be explicit
here:

a) scope the previous connection from componentPool to componentPool so
it definitely runs and disappearance of the hash value results in
removal (this scenario may run with a dangling engine* in the lambda)

b) add another connection from engine to engine so hash key
disappearance also results in removal

this reliably fixes the random crashes to do with classBegin (where we
would eventually deference the dangling pointers from the hash)

BUG: 429027
FIXED-IN: 5.88.0
parent fd404d83
Loading
Loading
Loading
Pipeline #92649 failed with stage
in 50 seconds
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment