Repository navigation
[#inc-517] Add basic crashing test with asan (HW Asan, GWP-ASan)聽#962
Description
### 馃洃 Blocked by
- [ ] https://github.com/getsentry/sentry-java/pull/3189
- [ ] https://github.com/getsentry/sentry-native/pull/944
Activity
JoshuaMoelans commentedon Jan 31, 2025
Testing Address Sanitizers
This comment acts as a "what-we-already-tried" benchmark to work from, which can guide our next steps in resolving this issue. During the investigation of #974 I had a look into the following 3 ASAN types:
ASan
(Android Docs)
This first Address Sanitizer gave me actual results when trying to build an Android app with native C memory bug detection. For future reference, this might make the most sense to add as a first "basic crashing test".
To run ASan on an emulated Pixel 9 Pro (running Android 14.0 Default Android System Image, so we have Root access) I added the following to the sample app (found here):
In
/sample/cmakelists.txttarget_compile_options(ndk-sample PRIVATE -fsanitize=address -fno-omit-frame-pointer) target_link_options(ndk-sample PRIVATE -fsanitize=address) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=address -fno-omit-frame-pointer") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address -fno-omit-frame-pointer") set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fsanitize=address")And these to
/sample/build.gradle.ktsandsentry-native/ndk/lib/build.gradle.ktsexternalNativeBuild { cmake { arguments.add(0, "-DANDROID_STL=c++_shared") arguments.add(0, "-DSENTRY_NATIVE_SRC=$sentryNativeSrc") arguments.add("-DCMAKE_VERBOSE_MAKEFILE=ON") abiFilters.addAll(listOf("x86_64", "arm64-v8a")) abiFilters.forEach { abi -> println("ABI=$abi") if (abi == "arm64-v8a" || abi == "x86_64") { arguments.add(0, "-DANDROID_SANITIZE=address") } } } }After which I needed to copy
[your ndk folder]\toolchains\llvm\prebuilt\windows-x86_64\lib64\clang\9.0.9\lib\linux\libclang_rt.asan-aarch64-android.soto[your app]/src/main/jniLibs/arm64-v8a/(as instructed here)When running the following snippet, we get ASan output:
ASan output
GWP-ASan
(Android Docs)
This method relies on intercepting randomly chosen subsets of heap allocations to catch memory corruption bugs. This method isn't reliable enough for testing, since you'd need a large enough number of runs to find statistically significant results. It is meant more as a lightweight in-production ASan that, given enough users, will find heap memory safety bugs.
Enabling this for an app can be done by adding this to the
AndroidManifest.xmlfile:HW-ASan
(Android Docs)
Hardware-Assisted ASan can be useful, but needs device support. In my testing (only using emulated devices) this did not work (probably because it needs the actual hardware). In theory it catches a superset of ASan (the same bugs + stack use after return, plus it has lower RAM overhead)