| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
When decrementing "i", eventually i will equal zero. When that
happens, i-- underflows. This causes a crash when code which uses
clang's -fsanitize=unsigned-integer-overflow is run.
Avoid trigging an unsigned integer underflow.
Change-Id: I61709cb01f56fdb36d631aa95579e8bd09cafd12
|
|
|
|
|
|
|
|
| |
Change replyID-s from uint32_t to an object
Move reply handling into the loopers (to reuse a common mutex)
Bug: 19607784
Change-Id: Iaa035b846c424c5687ed17ce1079b325e86c54be
|
|
|
|
|
| |
Bug: 19607784
Change-Id: I4b2ca396fb50cde5e7dc9801add69037febe698d
|
|
|
|
|
|
|
| |
This avoids locking gLooperRoster mutex on post() and deliver().
Bug: 19607784
Change-Id: If6d9d7884dbb08fc390983bda896d223803476ba
|
|
|
|
|
|
|
|
| |
Print a list of looper-handler pairs and the number of messages
they've processed, and optionally break those stats out by
message type.
Change-Id: I68ce4a7003152d5c9b5cb3f42e6f3949b471aa6e
|
|
|
|
|
| |
Bug: 17059501
Change-Id: I242f2859527bed2d6e275c27de94fb19f4dcdc28
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The scenario is that a call to unregisterStaleHandlers() is in progress,
and is holding a temporary sp<ALooper> reference to an active ALooper inside
of the loop. At this point the only other remaining external reference to
the ALooper goes away, so the temporary sp<ALooper> in the loop is now
the only reference keeping that object alive. When the loop iterates and
the sp<> goes out of scope, the ALooper destructor is called, which in turn
calls unregisterStaleHandlers again, resulting in a recursive lock.
Bug: 17300093
Change-Id: I116f2ffab4ae7c43b6bcf54a367ae6f9d77c9626
|
|
|
|
|
|
|
| |
upon the death of an ALooper.
Change-Id: I64c0835b8db04486204f3d0fa7173ee53708a116
related-to-bug: 10106648
|
|
|
|
|
|
|
| |
has successfully completed and a sufficient amount of data fetched,
and only then signals that preparation is completed.
Change-Id: I7684a14238b826909f518f2af506966e522dfcfc
|
|
|
|
|
|
|
| |
See https://android-git.corp.google.com/g/157065
Bug: 5449033
Change-Id: I00a4b904f9449e6f93b7fd35eac28640d7929e69
|
|
|
|
| |
Change-Id: Id6c7a08c34fd5cb6c4632f78ece9e7898b29e52c
|
|
|
|
|
|
|
|
|
|
| |
cause an assertion.
There are edge cases in which a handler attempts to unregister itself while on another thread a message fails to be delivered to that very handler and causes automatic unregistration. In this case the handler's good cleanup intentions are thwarted by the CHECK.
Change-Id: I4e41b5e7b619159ecce4856c15cccca031a28b5b
related-to-bug: 3101247
QA-impact: no(!!!) risk
|
|
|
|
|
|
| |
callsites.
Change-Id: I45fba7d60530ea0f233ac3695a97306b6dc1795c
|
|
|
|
| |
Change-Id: I038d69b0a34eda1bfc5216d92c837a5ddf4fb802
|
|
|
|
| |
Change-Id: Ic7087b8dcbc0d9abda272df0cb01b04b006f82ad
|
|
Change-Id: I11714dcaa647d0437a13e4c5b953b35e712da8f3
|