El Friday 26 February 2016, a les 01:37:57, Frank Reininghaus va escriure: > Hi everyone, > > sorry if most of you know about this already, but since it seems that > QStringLiterals are being introduced everywhere right now, I think > that it is important to raise awareness about the fact that this might > be more dangerous that it seems at first sight. > > QStringLiteral has the nice property that it stores the string data in > read-only memory and avoids heap allocations when it is used to > construct a QString. The QString, and any copies that are made, just > contain a pointer to read-only data. There is a very nice overview by > Olivier at > > https://woboq.com/blog/qstringliteral.html > > However, QString is still a non-POD type, even if it has been > constructed with QStringLiteral (or copied from such a QString), so > its destructor is being run, which accesses the read-only data, then > finds out that it's been made with QStringLiteral, such that no > refcount updates and deallocations are needed. > > This becomes a problem if the read-only data that the QString refers > to are not there any more, which can happen if the QString was stored > in a global static object from one library, and the QStringLiteral is > from another library, which might have been unloaded before the global > static object was destroyed. > > I believe that this is just what happens right now with a global > static KIconLoader from kicontnkhemes and a QStringLiteral from > frameworkintegration: > > https://bugs.kde.org/show_bug.cgi?id=359758 > > If my analysis is wrong, please let me know!
If you know what commit causes it I'd say you have two options: * Find exactly which of the changes in the patch is causing the problem, add a test case that crashes and then commit the smallest change that fixes the crash * Revert the commit and CC the person that did the commit asking him to be more careful. Cheers, Albert _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel