Changing __android_log_write so the tag warns users relying on the
tag to direct log output to the radio buffer to instead use Rlog or RLOG.
Change-Id: I04b7bb5e620c1ab22b9b495382a252b539947e28
Both libraries are needed to build four shared libraries in 64-bit
for 64-bit emulator with "-gpu on"
lib64OpenglRender.so
lib64EGL_translator.so
lib64GLES_CM_translator.so
lib64GLES_V2_translator.so
Change-Id: If57f72d4661a74f1d5e537568881f39132e0b43d
1. In printf, use "%zu" for variable of type size_t
2. Print tid in %5d
3. Make type of pid/tid in AndroidLogEntry and logger_entry consistent
Change-Id: I3e3d9536ee58823f349a4734ae093d30eabe1bfe
Testing:
The following test cases all passed and generated log entries:
# echo -n '\03foo\0bar\0' > /dev/log/main
# echo -n '\03\0bar\0' > /dev/log/main
# echo -n '\03\0a\0' > /dev/log/main
The following entries were successfully processed by
logcat but produced no log entries:
# echo -n '\03\0\0' > /dev/log/main
# echo -n '\03a\0\0' > /dev/log/main
# echo -n '\03b\0\0' > /dev/log/main
Also tested the pathological error condition:
cat /dev/urandom > /dev/log/main
which produced many "+++ LOG: malformed log entry" errors.
Bug: 5478600
Change-Id: I53bc79507242dcfc14445746c29edf47be0a90b4
When parsing log entries which may have embedded \0s, it's
possible for entry->messageLen to not be the actual
length of the string in entry->message. Detect this condition.
Bug: 5417417
Change-Id: I712cac7696af7831e24765b5a1b345d6ff5fb407
Invoking LOG_ASSERT, LOG_ALWAYS_FATAL or LOG_ALWAYS_FATAL_IF variadic macros
without the printf format string arg caused compilation errors because the
variable arg list (__VA_ARGS__) was eventually passed to
__android_log_assert() func in place of a required parameter. This error
only occured in debug builds because LOG_ASSERT() is a no-op in release
builds. This change allows debug builds to succeed.
Change-Id: I7e7b7de3e501133468ce083e0e0d6e699dd59667
Signed-off-by: Chris Pearson <christopherx.c.pearson@intel.com>
snprintf has a weird return value. It returns what would have been written given a large enough buffer.
In the case that the prefix is longer then our buffer(128), it messes up the calculations below possibly causing heap corruption.
To avoid this we double check and set the length at the maximum (size minus null byte
Wink Saville