generate the old key before updating enabledborders
Summary: sometimes a frame changed enabled borders causing a dangling pointer in s_sharedFrames, since oldkey was generated with the new enabled borders, it generated a key not present in the hash, tryed to remove it and left the one associated with the old key in the hash. if the need to reuse a frame with that key ever arised again, we had a crash BUG:378508 Test Plan: couldn't reproduce the crash neither with or without patch, with the patch, if i put debug in every place a framedata is removed, searching if the key is in the hash before removing it, now it's always true, before sometimes it was false Reviewers: #plasma, davidedmundson Reviewed By: #plasma, davidedmundson Subscribers: plasma-devel, #frameworks Tags: #plasma, #frameworks Differential Revision: https://phabricator.kde.org/D6162
This commit is contained in:
parent
1aea7bbd5e
commit
6ffe068b80
|
@ -496,10 +496,9 @@ QPixmap FrameSvgPrivate::alphaMask()
|
|||
updateSizes(maskFrame);
|
||||
}
|
||||
|
||||
// maskFrame = frame;
|
||||
const QString oldKey = cacheId(maskFrame, maskPrefix);
|
||||
maskFrame->enabledBorders = frame->enabledBorders;
|
||||
if (maskFrame->cachedBackground.isNull() || maskFrame->frameSize != frameSize(frame)) {
|
||||
const QString oldKey = cacheId(maskFrame, maskPrefix);
|
||||
maskFrame->frameSize = frameSize(frame).toSize();
|
||||
const QString newKey = cacheId(maskFrame, maskPrefix);
|
||||
if (s_sharedFrames[q->theme()->d].contains(oldKey)) {
|
||||
|
|
Loading…
Reference in New Issue
Block a user