Note that init.zygote64.rc, which supports a "pure"
64 bit zygote is around only for testing.
The life cycles of both zygotes are controlled by init,
and the assumption here is that they will be available
always. We start the system_server in 32 bit mode.
Note that the distinction between "primary" and "secondary"
simply defines the order in which ABI support is queried,
there's no real requirement that the primary zygote supports
the primary ABI of the device.
bug: 13647418
Change-Id: Id0be001ea6f934c3c2022d89a63aae9fae66cc38
Fixes a leak and use-after-free if a client passes in an
already-allocated target buffer (currently none do)
Change-Id: Ie20c30bd5ba31e1b6db73885bd9d2ebd7e40dc27
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Initial commit for an audit daemon that writes kernel audit
messages to the Android logger. The daemon searches dmesg
for all lines that contain "audit" and writes them. Then
receiving the messages from the netlink socket.
It also formats the messages so they are compatable with
ausearch (type=<t> <m> format)
Modified: Mark Salyzyn <salyzyn@google.com>
- do not start auditd
- merge into logd, stripping unnecessary file logging.
- Convert headers and code to support C++
- Fix bugs in libaudit
- squash timestamp (replace with 0.0) due to duplication
- squash pid due to duplication
- squash comm due to duplication
Change-Id: I421bcf33e7e670d596628b1b5c7c25536ce2d3fe
The way libunwind handles local unwinds is different from remote unwinds,
so create a new map object to handle the differences.
Add new test to verify the map data is being generated correctly.
Add new tests to check for leaks.
Refactor the BACK_LOGW code into a single header file.
Change-Id: I01f3cbfc4b927646174ea1b614fa25d23b9b3427
A normal sequence of calls is as follows:
str_parms_create_str, str_parms_add_str, str_parms_destroy.
In some cases the destroy caused double free.
str_parms_add_str will clone the input and send it to hashmapPut
for storage. If hashmapPut did not store the strings it will raise
errno = ENOMEM and leave caller with ownership of the strings.
In any of these cases it will be safe to destroy the str_parms.
But what if it wasn't hashmapPut that said NOMEM? What if there
was a stale NOMEM already before a successful hashmapPut?
In that case the strings will be successfully added to the list
(if new), but when str_parms_add_str sees the NOMEM it will free
them anyway, leaving dangling pointers in the str_parms!!
It is the responsibility of the caller to clear errno before any
interesting call. This patch makes sure that str_parms_add_str
reacts only on errno emmitted from hashmapPut.
Change-Id: If87e4bcc482f09e1c66133d33517b152ebdac65f
