-
Notifications
You must be signed in to change notification settings - Fork 44
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
NDK crash in libdartjni.so (GetApplicationContext+60)
when uploading to Play Store
#1150
Comments
|
Do I do that in my project via Do you know if
I would have to create a whole new app consisting of just the cronet client, do all the Play Store setup for the app, and upload it for testing, to try to recreate the crash with the smallest amount of code possible (and I really can't afford the time to do something like that for a few weeks, because I'm about to launch my app). It doesn't crash on my local device or emulator, but I don't know what would be different about the Play Store... |
Here is how I call into cronet, however... this would be close to my minimal repro case: void main() async {
// Set up better http clients on Android and iOS
if (Platform.isAndroid) {
final engine =
CronetEngine.build(cacheMode: CacheMode.memory, cacheMaxSize: 1000000);
runWithClient(_run, () => CronetClient.fromCronetEngine(engine));
} else if (Platform.isIOS || Platform.isMacOS) {
final config = URLSessionConfiguration.ephemeralSessionConfiguration()
..cache = URLCache.withCapacity(memoryCapacity: 1000000);
runWithClient(_run, () => CupertinoClient.fromSessionConfiguration(config));
} else {
// Run with the default IOClient
_run();
}
}
void _run() async {
// Must come first
WidgetsFlutterBinding.ensureInitialized();
// Call runApp from here...
} |
Thanks for the quick reply.
You can use this dependency:
I regenerated the bindings as well, so it will work just fine.
I'll try to upload a cronet example app to play store to see if I get the same error. |
Thanks, awesome, that build saved me a lot of work! I'll replace this dep and see if it fixes the crash. |
While I have your attention -- is all of JNI deprecated in Android, or does
|
The PR is here: dart-lang/http#1198
Haha, I just had this conversation here: dart-lang/http#1198 (comment) It's not about JNI, it's something related to the way Flutter plugins work. I thought I have suppressed the warning, so users don't get confused by this message. However it seems that simply importing the deprecated class triggers the warning, so I should use the fully qualified name of the package instead of importing it. You can safely ignore it, and I'll hide the warning in the next release of |
Any updates on this? |
Hi, I have been stuck on iOS build issues, so I haven't uploaded my Android app again to the Play store (and even back when I was uploading periodically, I only saw this specific crash once), but it's possible that one of the recent crash fixes in You presumably know a lot about JNI already, but I figured I'd send you this link to a JNI project I created a while back. I found I had to very carefully check every incoming parameter (including ensuring that the user is not trying to call a static method in a non-static way or vice versa, etc.), and the https://github.com/toolfactory/narcissus/blob/main/src/main/c/narcissus.c |
Thanks for sharing. We do similar things, but instead of using C macros, it's a Dart script that generates a "safer" C API that wraps JNI. Closing this for now, let me know if your problem persists. |
Hi @HosseinYousefi -- with latest Can you please re-open this issue? It seems that Lines 116 to 119 in 1549dc8
This also seems to be a race condition, because it is only triggered in certain builds or certain execution environments. So this bascially means that |
@HosseinYousefi Any ideas how to go about debugging what is going on here? |
We recently had an issue regarding 32-bit devices, can you check if the devices with the error happen to be 32-bit? I have a PR to fix cronet, the new version will be published soon: dart-lang/http#1225 |
@HosseinYousefi No, it's a Pixel 7 Pro, so it's a 64-bit device. I looked through how the plugin is registered, and I can't see how |
Where do you actually see the error being about One theory: we have not been calling |
Unfortunately I have only seen this on release and profile builds, and I have not been able to symbolize the stacktraces. But it's crashing in It is sporadic, and right now I can't replicate it, but it keeps resurfacing. |
Your fix for #557 doesn't zero-out However the note in #557 may have identified the problem:
So potentially |
I just checked the reproducibility, and this crash has occurred 100% of the time in the testing phase of five different build uploads to Google Play. Locally, I used to be able to reproduce this in Profile builds, but that somehow spontaneously fixed itself without any code changes, after clearing build files and re-building. This is a total showstopper for my app, because I can't even get through Play Store app review without the app crashing on load. I may have to launch without cronet. |
If you're just making a thread-local copy of a single global |
We use
Another thread would have a different
No, the
static inline void attach_thread() {
if (jniEnv == NULL) {
(*jni->jvm)->AttachCurrentThread(jni->jvm, __ENVP_CAST & jniEnv, NULL);
}
}
As this is a problem with cronet, can you please open an issue there as well? You can simply link to this one. Unfortunately without a reproducible example, or logs I can't start the debugging process on my end. |
@HosseinYousefi I created the Cronet bug and test project as requested: dart-lang/http#1241 This test project doesn't crash on my machine, but the release build does lock up. |
I can't reproduce the locking up of release build. |
@HosseinYousefi Is there anything else I can do to debug this? |
Well, as you cannot reproduce it on your machine, and I don't seem to be able to reproduce it on mine, there is nothing we can do to fix it this way. You say that the play store's checks fail. Can you share a minimal app that fails the play store checks? This way at least I can create a play store account and iterate to see what makes it fail. You are the only person reporting this bug, so I highly doubt the example is going to be as simple as just initializing cronet. |
I am able to reproduce the lock-up issue on my machine with the minimal repro code that I shared. That code just does not crash in the same way as I originally reported -- but it should not lock up, so this is still worth looking into. Any tips for how to debug what is happening on my machine with that example?
The crash happens before Flutter starts, and the only thing that my app does after initializing cronet is to start Flutter. I looked to see if any other plugins use JNI, and there aren't any. Possibly this is a memory corruption bug. |
These are probably separate issues, I'm talking about the original crash. The lock-up issue might be a cronet specific one. In any case these are some steps you can take: What is the output of your |
I'm now pretty sure that the problem is not jni-related. Closing this issue. Let's continue any further discussions in the http thread. |
I am getting an NDK crash in
libdartjni.so (GetApplicationContext+60)
when I upload my APK to the Play Store.Any ideas?
The text was updated successfully, but these errors were encountered: