Fix bug in TextLayoutCacheKey handling embedded nulls.
We were not passing the length of the UTF-16 string to
String16::setTo. As a result, it was copying the contents of
the text up to the first null it found.
First problem, these strings are not typically null terminated!
Second problem, if the string contained a null character, then
we might truncate it. However, we only truncated the string
when the copy constructor was invoked (say, when we called
get() on the cache) but not in internalTextCopy() (before
adding the key to the cache).
As a result of the second problem, we would first search
the cache for a key that matched a partially copied truncated
string (potentially reading uninitialized memory that followed it).
Finding none, we would add the entry to the cache using
the correct key.
If the cache already had a value associated with the correct key,
then the put would fail, returning false. Charging ever onwards,
we would add the size of the entry to the cache size.
Proceeding in this manner, it was possible for the cache to
believe it had less remaining space than it really did. At that
point, it was possible for the cache to evict all entries and
yet still not think it had room to add a new one, so it would
continue trying to make space indefinitely.
Bug: 5576812
Change-Id: I05251594f6b2da0a5dc09f7200f04fe9100ec766
diff --git a/core/jni/android/graphics/TextLayoutCache.cpp b/core/jni/android/graphics/TextLayoutCache.cpp
index 7db8abd..f67b8b1 100644
--- a/core/jni/android/graphics/TextLayoutCache.cpp
+++ b/core/jni/android/graphics/TextLayoutCache.cpp
@@ -249,7 +249,7 @@
flags(other.flags),
hinting(other.hinting) {
if (other.text) {
- textCopy.setTo(other.text);
+ textCopy.setTo(other.text, other.contextCount);
}
}
