Check internal JNI calls for pending exceptions and no-op #1088
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Goal
Makes safe all invocations of
GetMethodId
,GetStaticMethodId
, andFindClass
within the NDK module. This is achieved by calling ExceptionClear to remove any pending JVM exceptions that could lead to app termination. The return value of all these invocations is checked forNULL
, and no-ops if this is the case.Changeset
FindClass
withbsg_safe_find_class
(and equivalents forGetMethodId/GetStaticMethodId
)NULL
. The following errors can be thrown. As these are not recoverable, Bugsnag should no-op rather than crashing the process:NoSuchMethodError
ExceptionInInitializerError
OutOfMemoryError
ClassFormatError
ClassCircularityError
NoClassDefFoundError
NULL
and no-op in this caseTesting
Relied on existing test coverage.
Remaining work
The ANR plugin has not been converted to use these safe calls yet as it cannot directly access the methods. There are also several other JNI calls which can throw errors that Bugsnag does not currently handle. Both these will be addressed in separate changesets.