Question about FORTIFY_SOURCE flag

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about FORTIFY_SOURCE flag

seal2002
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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/dce50cae-7a07-4c41-83c5-9bf11c3c5859n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Question about FORTIFY_SOURCE flag

Dan Albert
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).

On Thu, Jul 30, 2020 at 2:47 AM seal2002 <[hidden email]> wrote:
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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/dce50cae-7a07-4c41-83c5-9bf11c3c5859n%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAFVaGhuY7KQvqaz8bGPvEE8DDCLQ-6ECQ_4GuTr2dLsR0232ew%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Question about FORTIFY_SOURCE flag

Dan Albert
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.

On Tue, Aug 4, 2020 at 12:56 PM Dan Albert <[hidden email]> wrote:
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).

On Thu, Jul 30, 2020 at 2:47 AM seal2002 <[hidden email]> wrote:
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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/dce50cae-7a07-4c41-83c5-9bf11c3c5859n%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAFVaGhta5t3Gm9JJVWacu0h49samzgC2Mugxk1zpkTQWKg%2BG-Q%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Question about FORTIFY_SOURCE flag

seal2002
Thanks for clear information. Got the ideas.

On Wednesday, August 5, 2020 at 3:22:55 AM UTC+7 Dan Albert wrote:
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.

On Tue, Aug 4, 2020 at 12:56 PM Dan Albert <[hidden email]> wrote:
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).

On Thu, Jul 30, 2020 at 2:47 AM seal2002 <[hidden email]> wrote:
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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/dce50cae-7a07-4c41-83c5-9bf11c3c5859n%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/d80302ad-2398-404f-a84b-2cb8cc6f8394n%40googlegroups.com.