String metadata is being trimmed to 63 characters (native crashes)
pavlos-lyft opened this issue · 1 comments
Describe the bug
If I report a string metadata which length is larger than 63 characters, it is being cropped for native crash events.
For example, if I want to report this string as metadata:
123456789_123456789_123456789_123456789_123456789_123456789_123456789_
The following value will be displayed in Bugsnag dashboard (which length is 63 chars):
123456789_123456789_123456789_123456789_123456789_123456789_123
What's interesting is that if I set this metadata in addOnSend
function (on next session after crash) using event.addMetadata
- the string will be reported correctly without any trimming. Probably, the issue might be related to a metadata caching mechanism.
Steps to reproduce
I've added this use case to a simple application from this issue.
It is based on Bugsnag sample application.
- Simulate native crash
- Run the app
- Check the dashboard -
TEST_TAB
tab. longString
is trimmed butanotherLongString
is not trimmed (because it's set inaddOnSend
callback).
All the important code could be found in ExampleApplication.kt
file. Here is the metadata that is being trimmed and here is the metadata that is being reported correctly (due to being set in addOnSend
callback)
Environment
- Android version: 12
- Bugsnag version: 5.20.0
- Emulator or physical device: Physical device
Example Repo
Hey @pavlos-lyft 👋 , thanks for the issue and reproduction example. I can confirm we're seeing the same as yourself. I'm afraid this is a known issue. Strings set in the NDK layer are limited to a maximum of 64 characters, but due to the inclusion of a null terminator, the string will be truncated to 63 characters.
The reason that you see the string with length >= 64 characters when added in the addOnSend
callback (available from https://github.com/bugsnag/bugsnag-android/releases/tag/v5.16.0 onwards) is because this runs in the JVM layer, it allows for an unlimited string to be added, so this would be a suitable workaround if the value you're looking to add is available on relaunch of the application, you can augment the report in the JVM layer.
This is an issue that would be resolved with fixes to #1625, so I'm closing this issue in favour of that one as it's already linked to our internal roadmap :)