Oxygen: Fix QCache usage
Review Request #127866 - Created May 8, 2016 and submitted
This should mostly complete the QCache fixes I kicked off in a previous RR, 127837. Hugo noted there were many other similar usages, and boy he wasn't kidding! ;) The long story short is that these usages can theoretically cause use-after-free behavior (which can lead to crashes and even undefined behavior if the compiler ever gets smart).
NOTE It is -much- easier to review if you download the diff to your git repository for oxygen and then run "git diff -b" to ignore whitespace changes, particularly for the QPixmap changes.
For QPixmaps we return values instead of pointers, so we simply make a separate copy to be cached when we do insert. For QColor we return references to values so we must return pointers, and those have to be owned by a QCache to avoid memleaks. So I added a helper function to loop until the cache accepts the new entry. TileSets are a similar concern, except those have manual loops since I was uncertain about whether TileSet's copy constructor was the best idea or not.
This fixes a ton of Coverity issues (59717 - 259733, 259739, 259742 - 259752, 1336154, 1336155) and might be associated with Qt bug 38142 and KDE bug 219055 (which doesn't actually appear to be a dupe of a different bug to me...).
Compiled without warnings, installed and ran
oxygen-demo5 -style oxygen. Used the GUI Benchmark feature to automatically cycle through all the listed features -- no crashes or obvious rendering errors.
To be honest, I am quite puzzle by this whole thing.
Now, every insertion in the cache requires at least two searches in there and (in many case) at least one copy constructor being called. This is quite expansive ... (even though this happens only if the object is not found in the cache).
Also: not sure I understand what issue we are trying to fix and how: why is it that if the object inserted in the cache is immediately deleted, just retrying an indefinite amount of time will "fix" the issue. Are we not just transforming a crash into a freeze (infinite loop) ?
The Qt documentation is very vague about cases where the object is deleted immediately, and the only case it mentions is: " In particular, if cost is greater than maxCost(), the object will be deleted immediately."
Well, in such cases (that should not appear here), the infinite loop will not help. Right ?
Since we have no idea on how "predictible" the other deletion cases are, I don't think the fix is a good fix.
Does that mean that we should change the code in order to use references rather than pointer everywhere ? (as you did in the first patch on this topic) ?
Or get rid of using QCache (because this absence of guarantee at the insertion stage is too much of a pain to handle) ?
Or just commit and wait for bug reports about freezes ? (but with a happy coverty) ?
Updates patch based on much of the feedback, with major reverts to the way I approached TileSets and QColor in particular. For the TileSets I went ahead and implemented what I was talking about regarding a simple FIFO-based cache that holds shared pointers. I used QSharedPointer<> for this since it doesn't require subclassing from QSharedData -- but if this is the only part of the code that uses TileSet it might make sense to subclass from QSharedData instead. Although it builds, installs, makes it through oxygen-demo5 benchmark and all the rest, I'm not sure if the return value changes for TileSet are ABI-safe (do we track public API for this part of Oxygen? Does anything in a different library or application link to this?). On the other hand, if we can change return value, we should also be able to do that for QColor which will significantly improve that portion of the code, as right now the code doesn't 'cache' QColor at all anymore, we just dump them into a QMap that stays alive throughout the process lifetime. After reviewing the QCache sources I'm pretty sure this is all actually only a problem if you try to ::insert() into QCache with a cost > maxCost -- but we have codepaths in Oxygen that appear to lead to either reducing maxCost or disabling the cache entirely so I can understand why Coverity would be wary. But as long as we've convinced that we're not ever inserting entries into a cache with an invalid cost, I can also just flag those Coverity entries to be ignored if that would be easier, and then drop this RR.
Revision 2 (+401 -303)
+1 from me - looks much better without the while loops indeed :-)
Do you know what the maximum cache limit that will be set with FIFOCache::setMaxCost is? I'm asking because FIFOCache::find is linear in the cache size. It might be a problem if this is potentially unlimited, but if it's never much more than the default value of 256, then it probabaly doesn't matter much, because the runtime cost of re-generating the cached values is probably much larger.
FIFOCache looks like a simple solution to the problems that Coverity found with QCache (at least if the max cost is bounded) - nice!
thanks for the updated patch. No more objection.
Just wanted to mention that in principle, tileset could probably be passed around by value too: they are "mostly" only a QVector<QPixmap> (which would be implicitely cached, right ?), and a bunch of integers. So that copying them should not involve too much operations.