Under some unknown circumstances, debuggerd could become unresponsive.
If you try and take a bugreport during this time, it will hang forever.
Adding functions that have a timeout will allow dumpstate to stop if
dumping is taking too long.
Bug: 18766581
(cherry picked from commit 5f2ff6a910)
Change-Id: I39e8e9c60209e3ef9efac795fedb8e1edce2bd3e
Packets captured and logged by the NFLOG target are unicast, so
extend to catch and decode them. To avoid escaping issues, the raw
contents are passed around as hex strings.
Bug: 18335678
Change-Id: Ib7299500baa00080a1f000f9da843eb527363353
This works around a bug on on 64 bit kernels + sdcard daemons
where we were using memory addresses as inode numbers.
bug: 19012244
(cherry picked from commit faa0935ffb)
Change-Id: Idbf9e285e507e702e04e7461a10153df68ef2322
Under some unknown circumstances, debuggerd could become unresponsive.
If you try and take a bugreport during this time, it will hang forever.
Adding functions that have a timeout will allow dumpstate to stop if
dumping is taking too long.
Bug: 18766581
Change-Id: I85053b8dcfe6224e2b64b4d8f7f2ef448b3cda34
In a scenario in which an on-line (blocking) client is running and
a clean is attempted (logcat -c), the following can be observed:
1) the on-line logger seems to freeze
2) any other clear attempt will have no effect
What is actually happening:
In this case prune function will "instruct" the oldest timeEntry
to skip a huge number (very close to ULONG_MAX) of messages, this
being the cause of 1.
Since the consumer thread will skip all the log entries, mStart
updating will also be skipped. So a new cleaning attempt will have
the same oldest entry, nothing will be done.
Fix description:
a. keep a separated skipAhead count for individual log buffers (log_id_t)
LogTimeEntry::LogTimeEntry
LogTimeEntry::FilterSecondPass
LogTimeEntry::skipAhead
LogTimeEntry::riggerSkip_Locked
b. update LogTimeEntry::mStart even if the current message is skipped
LogTimeEntry::FilterSecondPass
c. while pruning, only take into account the LogTimeEntrys that are monitoring
the log_id in question, and provide a public method of checking this.
LogTimeEntry::isWatching
LogTimeEntry::FilterFirstPass
LogTimeEntry::FilterSecondPass
d. Reset the skip cont befor the client thtread starts to sleep, at this point
we should be up to date.
LogTimeEntry::cleanSkip_Locked
LogTimeEntry::threadStart
Change-Id: I1b369dc5b02476e633e52578266a644e37e188a5
Signed-off-by: TraianX Schiau <traianx.schiau@intel.com>
Replace the use of CFStringGetCString with kCFStringEncodingASCII specified
with CFStringGetFileSystemRepresentation which will ensure the correct
character encoding is used to conver the CFString into a NULL terminated
char array suitable for use with POSIX APIs.
(cherry picked from commit 2a4b5f9e80)
Change-Id: Ie6e2027e59b49ca634c7308bcda7bb492d372f46
The previous implementation returned the path the executable was in instead
of returning the path including the executable (i.e. it returned ...bin
instead of ...bin/executable). This is not what the original methods did
and caused the process forking of adb to fail.
This patch corrects the implementation.
(cherry picked from commit 26b53bb75e)
Change-Id: Icad6870bbb0a88f611ca71d90fff30f7b576c367
Recent versions of XCode fail to compile the adb and fastboot binaries due to
two functions being deprecated in 10.9 (GetCurrentProcess and
ProcessInformationCopyDictionary), and the use of -Werrror.
This patch replaces the method implementations which use calls to methods
deprecated in the 10.9 SDK with versions which only call non-deprecated methods.
(cherry picked from commit f456d47c50)
Change-Id: Ibd80dda73ccdd7c561b50b4065581e645d9855d6
/dev/pmsg0 used to record the Android log messages, then
on reboot /sys/fs/pstore/pmsg-ramoops-0 provides a means
to pull and triage user-space activities leading
up to a panic. A companion to the pstore console logs.
Change-Id: Id92cacb8a30339ae10b8bf9e5d46bb0bd4a284c4
