tree 1337c3e4d996bb3528f9c92531a95ce30fd860c1
parent 557a93e104f1fec69ed05b2d0ff26c78bca4c5d6
author Jens Gulin <jens.gulin@sonymobile.com> 1391531882 +0100
committer Takeshi Aimi <takeshi.aimi@sonymobile.com> 1395707822 +0900

Solve three memory leaks related to PatchCache

A Patch can be fairly large, holding bitmap data, but
is also frequently leaked which adds to the severity.
The feature is used in many important processes such
as Home, SystemUI and Chrome.

The following leaks are solved:

1. The Patch itself was not always freed.
PatchCache::removeDeferred() can mark patches to be
cared for by PatchCache::clearGarbage(). But
mCache.remove() would only destroy the container
and the pointer, not the Patch object itself.

2. The vertices stored in the Patch at Patch::createMesh()
would always leak. The empty/default destructor in Patch
would not properly destroy "vertices" since it's just a
pointer.

3. A BufferBlock that's added to the mFreeBlocks
in PatchCache could leak. The leak happened when a
patch later needed the entire free block, because the
object was removed from the list but never deleted
in PatchCache::setupMesh().

Change-Id: I41e60824479230b67426fc546d3dbff294c8891f