Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: expose a module loader for Android thru sentry-native #1043

Merged
merged 23 commits into from
Nov 18, 2020

Conversation

marandaneto
Copy link
Contributor

@marandaneto marandaneto commented Nov 13, 2020

📢 Type of change

  • Bugfix
  • New feature
  • Enhancement
  • Refactoring

📜 Description

feat: expose a module loader for Android thru sentry-native

💡 Motivation and Context

Flutter apps when has split symbols enabled need the debug images for proper server symbolization and the Dart/Flutter API doesn't offer it natively.

💚 How did you test it?

📝 Checklist

  • I reviewed submitted code
  • I added tests to verify changes
  • All tests passing
  • No breaking changes

🔮 Next steps

@codecov-io
Copy link

codecov-io commented Nov 13, 2020

Codecov Report

Merging #1043 (af6f4d7) into main (ae8c568) will decrease coverage by 0.02%.
The diff coverage is 0.00%.

Impacted file tree graph

@@             Coverage Diff              @@
##               main    #1043      +/-   ##
============================================
- Coverage     72.06%   72.03%   -0.03%     
  Complexity     1338     1338              
============================================
  Files           138      138              
  Lines          4893     4895       +2     
  Branches        499      499              
============================================
  Hits           3526     3526              
- Misses         1106     1108       +2     
  Partials        261      261              
Impacted Files Coverage Δ Complexity Δ
...y/src/main/java/io/sentry/protocol/DebugImage.java 3.12% <0.00%> (-0.21%) 1.00 <0.00> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ae8c568...af6f4d7. Read the comment docs.

@marandaneto marandaneto marked this pull request as ready for review November 13, 2020 12:59
@marandaneto marandaneto requested review from Swatinem and a team November 13, 2020 13:00
Copy link
Member

@Swatinem Swatinem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

You should add the type, debug_id, code_id and debug_file props as well.

Copy link
Member

@philipphofmann philipphofmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The overall PR looks great. I have added a few important comments about naming and in which package to put the classes. Can we maybe also add an integration test for this?

Copy link
Member

@philipphofmann philipphofmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One important comment and a few nitpicks.

Copy link
Member

@philipphofmann philipphofmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only thing stopping me to approve this is to add some integration tests to validate that the JNI calls are working properly. Can we add some?

@marandaneto
Copy link
Contributor Author

The only thing stopping me to approve this is to add some integration tests to validate that the JNI calls are working properly. Can we add some?

all good then, we can't run Android native code on the JVM, so we can't really do it.
Ideally, this is gonna be tested along with our E2E tests which are not there yet.

Copy link
Member

@philipphofmann philipphofmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As said integration tests would make sense, but we had some trouble in the past adding them and we don't want this to block this PR.

Copy link
Member

@bruno-garcia bruno-garcia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I worry that we do all this work to read a single entry (libapp.so) for Flutter only. Wouldn't it make sense to add a single: getByImageName or by id or something?


JNIEXPORT jobjectArray JNICALL
Java_io_sentry_android_ndk_NativeModuleListLoader_nativeLoadModuleList(JNIEnv *env, jclass cls) {
sentry_value_t image_list_t = sentry_get_modules_list();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we drop the _t? or is this really a type

Suggested change
sentry_value_t image_list_t = sentry_get_modules_list();
sentry_value_t image_list = sentry_get_modules_list();

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well unless we rename jobjectArray but either of them needs a suffix or prefix, as they are the same thing but using a different data type

jobjectArray image_list = NULL;

if (sentry_value_get_type(image_list_t) == SENTRY_VALUE_TYPE_LIST) {
size_t len_t = sentry_value_get_length(image_list_t);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
size_t len_t = sentry_value_get_length(image_list_t);
size_t len = sentry_value_get_length(image_list_t);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (sentry_value_get_type(image_list_t) == SENTRY_VALUE_TYPE_LIST) {
size_t len_t = sentry_value_get_length(image_list_t);

jclass image_class = (*env)->FindClass(env, "io/sentry/protocol/DebugImage");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we expect this method to be called multiple times? I wonder if would be worth caching these FindClass results

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unless somebody call clearDebugImages its used only once

sentry_value_t image_t = sentry_value_get_by_index(image_list_t, i);

if (!sentry_value_is_null(image_t)) {
jobject image = (*env)->NewObject(env, image_class, image_addr_ctor);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when/where is this freed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

after talking to @Swatinem this was not necessary, maybe after #1050 this is worth another review?
@Swatinem mind reviewing this part again?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks fine from my side. TBH, I have no idea how the ownership transfer works for these JNI object, and if the GC will ever run concurrently with this call? If we would need to manually root these things on the C stack, or if we need to unref them rather.

@marandaneto
Copy link
Contributor Author

I worry that we do all this work to read a single entry (libapp.so) for Flutter only. Wouldn't it make sense to add a single: getByImageName or by id or something?

doing a string.contains('libapp') is suboptimal IMO and not worth the savings

sentry_value_t image_t = sentry_value_get_by_index(image_list_t, i);

if (!sentry_value_is_null(image_t)) {
jobject image = (*env)->NewObject(env, image_class, image_addr_ctor);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks fine from my side. TBH, I have no idea how the ownership transfer works for these JNI object, and if the GC will ever run concurrently with this call? If we would need to manually root these things on the C stack, or if we need to unref them rather.

@marandaneto marandaneto merged commit b98169a into main Nov 18, 2020
@marandaneto marandaneto deleted the feat/module_loader branch November 18, 2020 14:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants