Package
Sentry
.NET Flavor
.NET
.NET Version
9.0
OS
Android
OS Version
No response
Development Environment
Visual Studio v18.x
Other Error Monitoring Solution
Yes
Other Error Monitoring Solution Name
No response
SDK Version
Sentry.Maui 5.16.3, sentry.native.android.dotnet 0.11.3
Self-Hosted Sentry Version
No response
Workload Versions
.
UseSentry or SentrySdk.Init call
.
Steps to Reproduce
- Create a .NET MAUI app targeting net9.0-android
- Use Sentry.Maui version 5.16.3
- Build a Release AAB (Android App Bundle) for Play Store distribution with default AndroidUseAssemblyStore=true and Optimize=true
- Upload debug files (ELF symbols) via sentry-cli before the crash events are received (upload confirmed successful)
- Trigger a native SIGSEGV crash on an Android device
- Export the event JSON from Sentry and inspect debug_meta.images
Expected Result
The crash address should fall within one of the loaded image ranges in debug_meta.images, allowing Sentry's symbolicator to match the frame to an uploaded debug file and produce a symbolicated stack trace.
Actual Result
The crash frame shows symbolicator_status: unknown_image. When checking the crash address against all 528 entries in debug_meta.images using:
image_addr <= crash_address < image_addr + image_size
the crash address does not fall within any loaded image range. This was verified for multiple crash addresses from the same release. The debug_meta.images section is present in the event (so this is not the same as the missing debug_meta problem reported in other issues), but the memory region containing the crash address is simply not represented in the image list.
Native ELF debug files were confirmed uploaded to Sentry before the crash events were received.
Additional Context
The debug IDs present in debug_meta.images have corresponding files uploaded to Sentry. The crash is a native SIGSEGV.
The crash address does not fall within any image range, so there is no debug ID to search for in Project Settings > Debug Files.
The affected release is on net9.0-android (not net10.0-android), so the assembly store blob rename issue described in #4969 does not apply directly.
It is unclear whether the memory region containing the crash address is absent from the image list due to a stale module cache, a dynamically loaded library not being registered, or another cause specific to the net9.0-android AAB packaging format.
Workaround Attempted and Rejected
Setting false in the Release configuration is a confirmed workaround for missing debug_meta on net9.0-android. However this workaround cannot be used in a production AAB pipeline. When AndroidUseAssemblyStore=false is set, bundletool fails with errors such as:
Module files can be only in pre-defined directories, but found 'lib/arm64-v8a/Yadusurf.BusinessObjects.Net8.dll.config.so'
AndroidUseAssemblyStore=true must be kept for Play Store release builds for this case.
Questions for the Engineering Team
-
Is the module list captured at crash time on net9.0-android with sentry.native.android.dotnet 0.11.3 expected to include all loaded memory regions, including those from split_config.[arch].apk?
-
Is there a known gap in module list capture for net9.0-android Release AAB builds with AndroidUseAssemblyStore=true that could explain a crash address falling outside all registered image ranges?
-
Is there a version of Sentry.Maui newer than 5.16.3 that addresses this specific problem on net9.0-android with AndroidUseAssemblyStore=true? Or does this require a dedicated fix that has not yet been released?
-
Would upgrading to Sentry.Maui 6.x (without migrating to .NET 10) be expected to resolve this?
* GitHub issue opened on behalf of user. Intercom Ticket: https://app.intercom.com/a/inbox/onh0p2wm/inbox/admin/9954807/conversation/215474146387506 - Thanks team
Package
Sentry
.NET Flavor
.NET
.NET Version
9.0
OS
Android
OS Version
No response
Development Environment
Visual Studio v18.x
Other Error Monitoring Solution
Yes
Other Error Monitoring Solution Name
No response
SDK Version
Sentry.Maui 5.16.3, sentry.native.android.dotnet 0.11.3
Self-Hosted Sentry Version
No response
Workload Versions
.
UseSentry or SentrySdk.Init call
.
Steps to Reproduce
Expected Result
The crash address should fall within one of the loaded image ranges in debug_meta.images, allowing Sentry's symbolicator to match the frame to an uploaded debug file and produce a symbolicated stack trace.
Actual Result
The crash frame shows symbolicator_status: unknown_image. When checking the crash address against all 528 entries in debug_meta.images using:
image_addr <= crash_address < image_addr + image_sizethe crash address does not fall within any loaded image range. This was verified for multiple crash addresses from the same release. The debug_meta.images section is present in the event (so this is not the same as the missing debug_meta problem reported in other issues), but the memory region containing the crash address is simply not represented in the image list.
Native ELF debug files were confirmed uploaded to Sentry before the crash events were received.
Additional Context
The debug IDs present in debug_meta.images have corresponding files uploaded to Sentry. The crash is a native SIGSEGV.
The crash address does not fall within any image range, so there is no debug ID to search for in Project Settings > Debug Files.
The affected release is on net9.0-android (not net10.0-android), so the assembly store blob rename issue described in #4969 does not apply directly.
It is unclear whether the memory region containing the crash address is absent from the image list due to a stale module cache, a dynamically loaded library not being registered, or another cause specific to the net9.0-android AAB packaging format.
Workaround Attempted and Rejected
Setting false in the Release configuration is a confirmed workaround for missing debug_meta on net9.0-android. However this workaround cannot be used in a production AAB pipeline. When AndroidUseAssemblyStore=false is set, bundletool fails with errors such as:
Module files can be only in pre-defined directories, but found 'lib/arm64-v8a/Yadusurf.BusinessObjects.Net8.dll.config.so'
AndroidUseAssemblyStore=true must be kept for Play Store release builds for this case.
Questions for the Engineering Team
* GitHub issue opened on behalf of user. Intercom Ticket: https://app.intercom.com/a/inbox/onh0p2wm/inbox/admin/9954807/conversation/215474146387506 - Thanks team