https://bugs.kde.org/show_bug.cgi?id=429027
Harald Sitter <sit...@kde.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Version Fixed In| |5.88.0 Latest Commit| |https://invent.kde.org/fram | |eworks/kirigami/commit/5ee8 | |b2888fe092b2228ff410e2ee88e | |1ec558fb0 Resolution|--- |FIXED Status|ASSIGNED |RESOLVED --- Comment #46 from Harald Sitter <sit...@kde.org> --- Git commit 5ee8b2888fe092b2228ff410e2ee88e1ec558fb0 by Harald Sitter. Committed on 31/10/2021 at 08:09. Pushed by sitter into branch 'master'. 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) FIXED-IN: 5.88.0 M +6 -2 src/columnview.cpp https://invent.kde.org/frameworks/kirigami/commit/5ee8b2888fe092b2228ff410e2ee88e1ec558fb0 -- You are receiving this mail because: You are watching all bug changes.