https://bugs.kde.org/show_bug.cgi?id=379669
--- Comment #19 from RJVB <rjvber...@gmail.com> --- >From memory, my patch mostly introduces common-sense error handling, it doesn't change anything else in the hash internals. I don't understand those, so I keep my hands off. I don't even understand why my attempts at handling deviant situations gracefully actually work instead of just moving the location of the crash, but it's a fact that they do. I won't claim it's a fix, provided you can prove that the situations currently not being handled can be avoided with 100% reliability. But if you can't prove that then it's more than a workaround and IMHO a fix for the crashes and hangs I've been seeing. And in that light it makes a whole lot more sense than just letting the code crash (regardless whether through an abort or after doing something with potential side-effects). Call it a necessary and hopefully temporary evil if you will, at least for production builds where all those Q_ASSERT checks become no-ops. As a user of a supposedly serious productivity tool I'm usually not interested in getting random aborts in order to help iron out a poorly understood glitch somewhere: the code should make reasonable attempts to recover from such a glitch if that is in anyway possible. IIRC I have also observed crashes at runtime, possibly (probably) when unloading projects. -- You are receiving this mail because: You are watching all bug changes.