One possibility here is Google does not care whether Android has software, or possibly, is not aware that Android is a product they own
Conversation
UPDATE:
3
15
Replying to
(I have a vague memory that __***_chk is ASAN/UBSAN and you need to link against their libraries)
1
It's _FORTIFY_SOURCE. I think that particular symbol is actually something I landed upstream. Bionic is both forwards and backwards compatible (unlike glibc) by versioning symbols based on target API level. Maybe the library was built with a different target API than the app?
1
2
That's fascinating :O However I built this library myself, from the same cmake build that built the rest of the apk so's, and UBSAN definitely should not be on. I'm not familiar with FORTIFY_SOURCE… :(
2
_FORTIFY_SOURCE uses __builtin_object_size to do bounds checking for writes (in glibc) or both reads and writes (in Bionic) based on compiler detection of object sizes.
I think you have some kind of issue where the code is being built for a newer API than you're using it with.
2
2
Are you using the latest version of the SDK/NDK? Is it possible you're building for min API 25 with an old NDK version?
It could be this bug which was fixed:
android.googlesource.com/platform/bioni
Off-by-one error in one of the API version checks used for backwards/forwards compatibility.
1
I'm building for min sdk 21 target sdk 26, which I should go back and double check but I believe is the recommended numbers for the hardware platform I'm targeting. I haven't upgraded the ndk in a while, I'll try that. Thanks.
1
I looked more carefully at the verbose build and the "problem" .so is compiling all its C files with -D_FORTIFY_SOURCE=2 and the "working" .sos are compiling all their C files with -U_FORTIFY_SOURCE. Is this surprising?
1
Do I want FORTIFY_SOURCE on at all for a perf-critical app? Is this something which is appropriate for debug builds but maybe not release builds?
2
It's a security feature. It generally hardly adds any overhead since the detected size is always a compile-time constant and if it can't detect one at compile-time it doesn't use it. Generally only enabled when optimization is enabled since it depends on that to detect the sizes.
That specific fortify function issomething I got them to add upstream but I'm pretty sure my patch got stalled for months and they rewrote it to the new Clang-based approach:
android.googlesource.com/platform/bioni
They left me as the author but I don't think I really wrote what they landed.
1
1
Don't really understand how you're having problems since you don't seem to be in the niche scenario where that off-by-one error in the compile-time version check would matter. I'm also curious if that has to do with the patch being delayed and missing a whole release. *shrug*
1
Show replies