[libdartjni.so] dartjni.c - getMethodID about http

[atrope]

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]

[brianquinlan]

@HosseinYousefi Since this crash seems to be coming from package:jni.

[atrope]

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.

[atrope]

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!

[atrope]

Hi @HosseinYousefi, I just ran a test with 150 open/close cycles, and it appears to be fixed. 🙏🏻

[atrope]

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

[atrope]

@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]

@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.

[atrope]

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.

[HosseinYousefi]

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.

[atrope]

Hi @HosseinYousefi Do you have any tip if we can help you fixing this or just wait until you work on the fix?

[HosseinYousefi]

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.

[brianquinlan]

@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:
6873731

The call to .release() is suspicious but it looks like package:jni guards access to released objects.

[atrope]

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.

[brianquinlan]

@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]

@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.

[brianquinlan]

@HosseinYousefi Thanks! If there is anything that might need to be done on the cronet_http side, let me know.

[HosseinYousefi]

@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/

[brianquinlan]

This is fixed in package:cronet_http 1.2.0