Closed atrope closed 7 months ago
I Was able to repoduce in that test app (https://github.com/SuaMusica/cronet_http_test) It is not always, but when it happens it's in the first or second try.
I Changed the app so we don't need to Click the download button.
Also managed to pinpoint the error to the shutdown method in jni_bindings.dart when we fetch the _id_shutdown variable.
The way i can "reproduce" is to install the app in the phone and then keep the logcat running while closing and opening the app. It will eventually happen sometime after 10/20 opens.
I/flutter (11857): [Downloader] onDone: test2_2527382.jpg 2
I/flutter (11857): CLOSE
F/libc (11857): Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 11949 (DartWorker), pid 11857 (ple.cronet_test)
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/q4qxxx/q4q:14/UP1A.231005.007/F936BXXS5EXAB:user/release-keys'
Revision: '14'
ABI: 'arm64'
Processor: '7'
Timestamp: 2024-03-06 13:34:58.900456264-0300
Process uptime: 3s
Cmdline: com.example.cronet_test
pid: 11857, tid: 11949, name: DartWorker >>> com.example.cronet_test <<<
uid: 10848
tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
pac_enabled_keys: 000000000000000f (PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY)
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000000
Cause: null pointer dereference
x0 b400007272224a18 x1 000000705ca47600 x2 0000000000000008 x3 0000000000000010
x4 000000705ca47608 x5 b400007272224a20 x6 0000000000000000 x7 0000000000000000
x8 0000000000000000 x9 fffffffffffffff8 x10 000000002e5e8081 x11 0000000000000002
x12 0000000000000000 x13 ffffff91f9ffca6f x14 0000000000000000 x15 0000006fbfffa940
x16 000000705ca55228 x17 000000740eca8280 x18 0000006fbdf04000 x19 000000704245a820
x20 0000000000000006 x21 b4000071b21c44e0 x22 0000006e00008081 x23 0000000000000000
x24 0000006e00008081 x25 0000006fbff19000 x26 b4000071b21c44e0 x27 0000006e0569fae0
x28 000000080000006e x29 0000006fbfffa930
lr 000000705ca4a680 sp 0000006fbfffa900 pc 000000705ca4a684 pst 0000000080001000
2 total frames
backtrace:
#00 pc 000000000000a684 /data/app/~~ybpYcAoGzGDg6PGobeM9gg==/com.example.cronet_test-eYEVCr-Izq6OVce52gmfxg==/lib/arm64/libdartjni.so (getMethodID+40) (BuildId: 360ce44136186a19bc4625350cae4c4f927a9cd7)
#01 pc 0000000000007bc4 [anon:dart-code]
Hey, I Tried to debug a little bit more and got to this method here that i guess goes to the C part of things
I was not able to understand how i can debug the C part to check if the address is faulty.
What i can tell you is that it gets to this function with the right address
getMethodID cls: Pointer: address=0x3a26, name: Pointer: address=0xb4000071a21b6550, signature: Pointer: address=0xb4000071a21b85b0
And after that it crashes with the above error.
I Really got to the point that i don't know how to proceed. @brianquinlan If you could share some inputs maybe i can continue to try fixing this issue.
Thanks
@HosseinYousefi Since this crash seems to be coming from package:jni
.
@HosseinYousefi hi, Do you have any inputs on where I can try to fix this? It is affecting our Google play metrics. Thank you!
@HosseinYousefi hi, Do you have any inputs on where I can try to fix this? It is affecting our Google play metrics. Thank you!
I wasn't able to reproduce this on my device yet. I'll try it again and will let you know.
Gotcha. The way i can reproduce is:
1 - Install the test app in debug mode 2 - With the phone connected and active logcat just open and close the app. If it downloads more than 2 files(it becomes green) you can force close and open again(You dont need to reinstall the app only close and open, logcat should show all info). It will happen after maximum 20 tries it always does.
Gotcha. The way i can reproduce is:
1 - Install the test app in debug mode 2 - With the phone connected and active logcat just open and close the app. If it downloads more than 2 files(it becomes green) you can force close and open again(You dont need to reinstall the app only close and open, logcat should show all info). It will happen after maximum 20 tries it always does.
I managed to reproduce it, thanks. I will look into this.
Hi @HosseinYousefi Do you have any tip if we can help you fixing this or just wait until you work on the fix?
Hi @HosseinYousefi Do you have any tip if we can help you fixing this or just wait until you work on the fix?
I'm working on another issue at the moment so I can't prioritize this in the next few days. You can try enabling CheckJNI and debug the root cause yourselves.
@HosseinYousefi Also let me know if it looks like package:jni
is not the cause and I can start trying to debug package:cronet_http
.
This seems like the only relevant change since the last release: https://github.com/dart-lang/http/commit/6873731c7bdf14e2489587de66ad1a115b35747f
The call to .release()
is suspicious but it looks like package:jni
guards access to released objects.
I will also try to enable that option and debug more.
@brianquinlan I will Also will try to test without the release and check if it will also happen or not and if it does not, will check that the other bug also does not happens.
Following thorough testing for two hours, I discovered that eliminating release
from the close method somewhat mitigated (the issue surfaced after opening the app 40 times) but did not completely avert the crash linked to this problem.
Moreover, I tried downloading 2000 items, and issue #1136 did not manifest.
Putting release
back into the method led to the crash happening again on the tenth try of launching the test app.
Activating CheckJNI did not modify the result or offer additional clarity. The crash persisted, with the same parameters.
Quick update: By setting closeEngine
to false
, this issue is avoided (naturally, as neither shutdown nor release is executed), yet issue #1136 emerges as a result.
If anyone has further suggestions, please share them so we can attempt to replicate or resolve the problem.
Thank you!
@HosseinYousefi Will you have a chance to look at this in the short term? If not, let me know and I'll take a look.
@HosseinYousefi Will you have a chance to look at this in the short term? If not, let me know and I'll take a look.
I'm just done with my previous task. Will take a look tomorrow!
Feel free to take a look at it yourself as well today.
@HosseinYousefi Thanks! If there is anything that might need to be done on the cronet_http side, let me know.
@atrope Please try again to see if your problem persists after upgrading to jni: ^0.7.3
.
Upgrade your dependency like so:
cronet_http:
git:
url: https://github.com/dart-lang/http/
ref: upgrade-jni
path: pkgs/cronet_http/
Hi @HosseinYousefi, I just ran a test with 150 open/close cycles, and it appears to be fixed. 🙏🏻
This is fixed in package:cronet_http
1.2.0
Hey @brianquinlan After we applied the fix for. #1136 and released a new version we received from Android Store that our ANR rate is beyond the reasonable level for this specific error. Is it possible that we are trying to close a thread that does not exist anymore and then Android crashes? I Was able to receive the error but still not able to reproduce with confidence.. It started after we added the close engine.
It Affects all Android versions.