_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.
Conversation
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.
2
1
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
I vaguely remember being super frustrated with how long it took to land that little patch among other things and it was part of getting burnt out with trying to upstream things into LLVM, Linux and AOSP since I can't imagine landing actually complex stuff upstream.
1
So basically, the way Bionic is supposed to work is that it has proper version checks for all newly added stuff and has versioned symbol export lists for the NDK. It hides symbols for newer version for an app that's not supposed to see them. Presumably why the symbol isn't there.
1
As opposed to glibc where you have to build against the oldest glibc version you want to support, with Bionic, you can use the latest NDK and Bionic to build for an ancient release since they have these version checks. I guess it was screwed up for this specific symbol though.
I don't quite understand how you're actually hitting a problem with it but that's the general idea of how it's supposed to work.
I think what's probably actually happening is your build system is not passing the API level as it's supposed to when it's building these files.
1
The build system needs to be setting the minimum API level so that the code isn't built to use symbols introduced in newer versions. I don't think this actually has to do with that old minor SDK issue but rather this is the canary in the coal mine breaking from having that issue.
1
Show replies