Commit graph

5 commits

Author SHA1 Message Date
Steven Moreland
c2dc7cd31c libutils: LightRefBase: incStrongRequireStrong
Allow LightRefBase to be used with
ANDROID_UTILS_REF_BASE_DISABLE_IMPLICIT_CONSTRUCTION, mainly for
libhwui.

Bug: N/A
Test: libutils_test
Change-Id: I251c874a80f0a069572bc51da45f8f8e74ba6f5b
2021-05-04 21:42:26 +00:00
Steven Moreland
da75cef983 ANDROID_UTILS_REF_BASE_DISABLE_IMPLICIT_CONSTRUCTION
In form, inspired by ANDROID_BASE_UNIQUE_FD_DISABLE_IMPLICIT_CONVERSION.

We get occasional bugs about sp double-ownership. When this flag is
enabled, we have:
- you must construct RefBase objects using sp<>::make
- you must construct wp<> objects by converting them to sp<>
- if you want to convert a raw pointer to an sp<> object (this is
  possible since the refcount is used internally, and is used commonly
  on this*), then you must use 'assertStrongRefExists' semantics which
  aborts if there is no strong ref held. That is, if a client uses
  std::make_shared and then calls a function which internally used to
  call `sp<T>(this)`, you would now call
  `sp<T>::assertStrongRefExists(this)`, and the double ownership
  problem would become a runtime error.

Bug: 184190315
Test: libutils_test
Change-Id: Ie18d3146420df1808e3733027070ec234dda4e9d
2021-04-05 17:45:18 +00:00
Steven Moreland
401d69aa94 libutils: introduce sp<T>::make
This is in preparation of doing what we did for SharedRefBase (hiding
operator new) so that clients can't accidentally construct
shared_ptr/unique_ptr or any other alternative memory management scheme
which would conflict with RefBase. You can see what ultimately happened
to SharedRefBase in frameworks/native CL
10d9ddf2e3da3ba3a425fb8396aaaec728e5fbdb.

The goal for this:
- promote use of 'sp<T>::make' over 'sp<T> .. = new T'
- make 'operator new' a private member of RefBase

Bug: 138956784
Test: libutils_test
Change-Id: I47f4d28edbf7534730c7b6fb1de748dd60f34e11
2020-02-20 17:21:27 -08:00
Steven Moreland
306f8b5713 libutils: sp lh comparison w/ pointer
Perhaps the better question is, why have I 100s of times, typed
"ASSERT_NE(nullptr, foo)" for sp<> foo, and got a compiler error and
then change it to "foo.get()". This CL so we can stop wasting cycles
with that error.

Fixes: 147842528
Test: libutils_test
Change-Id: Id63b29d2a1ff3077201a62b69d864c5a826c47e0
2020-01-17 22:50:30 +00:00
Elliott Hughes
01705e4f1d Clean up libcutils/libutils tests.
Move tests in the same directory as the corresponding code, so it's
easier to see what is/isn't tested.

Fix naming of libcutils_tests (plural) to match the singular that's more
common (even though the plural makes more sense to me).

Add these two to system/core/'s TEST_MAPPING.

Remove obsolete AndroidTest.xml.

Fix a flaky (timing-dependent) libcutils test.

Test: ran tests
Change-Id: I7e0a31ff45c8a152562bf66fc97161594249366e
2019-02-11 13:15:56 -08:00
Renamed from libutils/tests/StrongPointer_test.cpp (Browse further)