Question about FORTIFY_SOURCE flag

291 views
Skip to first unread message

seal2002

unread,
Jul 30, 2020, 5:47:42 AM7/30/20
to android-ndk
Hello guys,

Recently version, My app has a crash related to Fortify on Play Console. StackTrace is below:

backtrace: #00 pc 0000000000083360 /apex/com.android.runtime/lib64/bionic/libc.so (abort+176) #01 pc 00000000000e5154 /apex/com.android.runtime/lib64/bionic/libc.so (__fortify_fatal(char const*, ...)+116) #02 pc 00000000000e484c /apex/com.android.runtime/lib64/bionic/libc.so (HandleUsingDestroyedMutex(pthread_mutex_t*, char const*)+52) #03 pc 00000000000e46ac /apex/com.android.runtime/lib64/bionic/libc.so (pthread_mutex_lock+164)
 #03  pc 00000000000e46ac  /apex/com.android.runtime/lib64/bionic/libc.so (pthread_mutex_lock+164)
  #04  pc 00000000041665f0  /data/app/com.sample.XXX-acbdMaf6U8z2l8nbfkYxeA==/lib/arm64/libSample.so (std::__ndk1::__libcpp_mutex_lock(pthread_mutex_t*)) (SourceCode: /buildbot/src/android/ndk-release-r21/external/libcxx/include/__threading_support:264)
  #05  pc 00000000041665f0  /data/app/com.sample.XXX-acbdMaf6U8z2l8nbfkYxeA==/lib/arm64/libSample.so (std::__ndk1::mutex::lock()) (SourceCode: /buildbot/src/android/ndk-release-r21/external/libcxx/src/mutex.cpp:33)
  #06  pc 0000000003f05430  /data/app/com.sample.XXX-acbdMaf6U8z2l8nbfkYxeA==/lib/arm64/libSample.so (Curl_share_lock) (SourceCode: C:\jenkins\workspace\Release_3rdParty_Windows\libs\common\Curl\src/share.c:236)
  #07  pc 0000000003f1f1dc  /data/app/com.sample.XXX-acbdMaf6U8z2l8nbfkYxeA==/lib/arm64/libSample.so (Curl_http) (SourceCode: C:\jenkins\workspace\Release_3rdParty_Windows\libs\common\Curl\src/http.c:2599)

First, I think it is use full, as I check on the source code at https://android.googlesource.com/platform/bionic/+/master/libc/bionic/pthread_mutex.cpp

Dealing with threading is difficult, the app crashes is better then it stucks :D.
So the questions are:
  1. I didn't add "-D_FORTIFY_SOURCE=2" for that Curl lib when compiling it 1 years ago with standalone toolchain. So do we need to add "-D_FORTIFY_SOURCE=2" to all C code to have the stacktrace as above?
  2. Is it only avalible on arm64-v8a?
Also, I suggest it should be support from SDK 23.

Thanks,
Seal

Dan Albert

unread,
Aug 4, 2020, 3:56:54 PM8/4/20
to android-ndk
I didn't add "-D_FORTIFY_SOURCE=2" for that Curl lib when compiling it 1 years ago with standalone toolchain. So do we need to add "-D_FORTIFY_SOURCE=2" to all C code to have the stacktrace as above?

_FORTIFY_SOURCE doesn't affect that. It should maybe be using a different abort function to make that more clear, but it is doing fortify-like things.

Is it only avalible on arm64-v8a?

Doesn't appear so.

Also, I suggest it should be support from SDK 23.

If you're referring to the targetSdkVersion check, we can't realistically change that because it breaks app compat. It lets apps that are already on the store that aren't symptomatic but would otherwise trigger this check continue to work on new OS versions, but also lets us help developers diagnose latent bugs when they update their targetSdkVersion (and since they'll test their apps before shipping them after making that change, it won't inadvertently affect users).

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/dce50cae-7a07-4c41-83c5-9bf11c3c5859n%40googlegroups.com.

Dan Albert

unread,
Aug 4, 2020, 4:22:55 PM8/4/20
to android-ndk
Oh, and as for "how do I enable this more widely", the only thing controlling this diagnostic is targetSdkVersion. apps with a targetSdkVersion of 28+ will get this diagnostic when they're running on a device that supports it. If you're not seeing this elsewhere, you're either using an older targetSdkVersion, not encountering the problem, or running on a device that's too old to have the check (the check was probably added in the same version as the targetSdkVersion check, so API 28 devices and up).

Assuming you have targetSdkVersion 28 or higher in all your apps, there's nothing you can do to get more thorough diagnostics for this particular bug.

seal2002

unread,
Aug 5, 2020, 5:18:38 AM8/5/20
to android-ndk
Thanks for clear information. Got the ideas.
Reply all
Reply to author
Forward
0 new messages