background:
we have some code to fix-up the IDs of references when
using RefBase's DEBUG_REFS when those refs are managed by
arrays wp<> or sp<> (this is because wp<> / sp<> don't have
a trivial ctor when DEBUG_REFS is enabled, and Vector
treats them as trivial for obvious performance reasons)
this is complicated by the fact that we don't want to have
to recompile everything when enabling DEBUG_REFs (i.e.: the
Vector code cannot know wheter it's enabled or not for its
template stuff).
problem:
there was a bug in the fix-up code for wp<> which was trying
to access the weakref_impl from the RefBase* however, this was
moronic since RefBase could have been destroyed if there wasn't
any more strong refs -- and this happned. Instead we need to get
the weakref_impl directly from the wp<>
Change-Id: Ie16e334204205fdbff142acb9faff8479a78450b
- stacks are now saved in /data/debug which must be
created and writable by the user.
- removed "always fatal" DEBUG_REFS option, it wasn't
really needed.
- DEBUG_REFS_ENABLED_BY_DEFAULT is not the default anymore
(usually people want to target which refs they're tracking)
Change-Id: I37fae72e9dacde6ce1fa8f7dbe2bc01b1a1b95e5
we would leak a weakref_impl if a RefBase was never incWeak()'ed.
there was also a dangling pointer that would cause memory corruption
and double-delete when a custom destroyer was used to delay the
execution of ~RefBase.
it turns out that the custom destroyer feature caused most of the
problems, so it's now gone. The only client was SurfaceFlinger
who now handles things on its own.
RefBase is essentially back its "gingerbread" state, but the
code was slightly cleaned-up.
Bug: 5151207, 5084978
Change-Id: Id6ef1d707f96d96366f75068f77b30e0ce2722a5
this bug was introduced recently. it caused RefBase's weakref_impl
structure to be leaked for every RefBase object (about 20 bytes).
Change-Id: Id85e749ba04521199555dd701198edd097c313d4
Fix a race that could cause GL commands to be executed from the wrong thread.
RefBase subclasses can now decide how they want to be destroyed.
Fix a race in SurfaceFlinger that could cause layers to be leaked forever.
Fix a race-condtion in SurfaceFlinger that could lead to a crash.
initial cherry-pick:
resolved conflicts for merge of b9783b49 to honeycomb-plus-aosp
Change-Id: I2a335e03fff219e35c18a7b0089b3a11d636576f
* commit 'c9cd2387b6938a6fbefc731d2177902266f2a130':
Fix a race that could cause GL commands to be executed from the wrong thread.
RefBase subclasses can now decide how they want to be destroyed.
Fix a race in SurfaceFlinger that could cause layers to be leaked forever.
Fix a race-condtion in SurfaceFlinger that could lead to a crash.
This adds a destroy() virtual on RefBase which
sublasses can implement. destroy() is called
in lieu of the destructor whenthe last strong
ref goes away.
Bug: 4483050
Change-Id: I8cbf6044a6fd3f01043a45592b5a60fa1e5fade2
Under Fedora 15 Beta, gcc 4.6.0 warns:
frameworks/base/libs/utils/RefBase.cpp: In member function
‘void android::RefBase::weakref_type::trackMe(bool, bool)’:
frameworks/base/libs/utils/RefBase.cpp:483:67: error: passing
‘const android::RefBase::weakref_impl’ as ‘this’ argument of
‘void android::RefBase::weakref_impl::trackMe(bool, bool)’
discards qualifiers [-fpermissive]
trackMe is not a const function, so don't use const in the static_cast
to a weakref_impl pointer.
Change-Id: I3c9ba73eb127985f5f54197ffecf2939c50f632c
some of the conversion operators were not using the proper
pointer type when calling incStrong/decStrong, usually it
has no bad consequences, but for some implementation
of the ref-counted object it could lead to recording the wrong
owner id.
Change-Id: If574b9069b8a4cf6e0911a992c8f095aba799995
First slipt sp<> out of RefBase into StrongPointer.h so it can be reused
more easily and to make it clear that it doesn't require RefBase.
Note: the rest of the change only affects the system when DEBUG_REFS is enabled.
The main problem we fix here is that the owner id associated with each
reference could get out of date when a sp<> or wp<> was moved, for
instance when they're used in a Vector< >.
We fix this issue by calling into RefBase::moveReferences from
a template specialization for sp<TYPE> and wp<TYPE> of the
type helpers. RefBase::moveReferences() has then a chance to
update the owner ids.
There is a little bit of trickery to implement this generically in
RefBase, where we need to use a templatized functor that can turn
a sp<TYPE>* casted to a void* into a RefBase*.
Introduced a new debug option DEBUG_REFS_FATAL_SANITY_CHECKS
currently set to 0 by default as there seem to be an issue
with sp<ANativeWindow> which trips the sanity checks.
Change-Id: I4825b21c8ec47d4a0ef35d760760ae0c9cdfbd7f
