[BUG] v4: Lost connection to device

[bmason8]

The app frequently crashes while (debug mode) moving the map around or shortly after moving around. Seems like zooming in and out can increase the likelihood that it happens.

*Important! This could be a flutter_map issue. I'm going to post this there as well.

Environment: M1 Macbook Pro - Android Studio Arctic Fox - 2020.3.1 Patch 4.
Using flutter_map_tile_caching v_4.0.0-dev.9

The most recent crash running on an emulator (Pixel 4a API 30) included this:

The following IsolateSpawnException was thrown while resolving an image:
Unable to spawn isolate: Could not prepare the child isolate to run.

When the exception was thrown, this was the stack: 
Image provider: FMTCImageProvider()
Image configuration: ImageConfiguration()
Image key: FMTCImageProvider()
====================================================================================================
Lost connection to device.```

Here is a more typical looking crash using an iPhone 7 running 14.7.1:

``` * thread #62, name = 'DartWorker', stop reason = EXC_BAD_ACCESS (code=1, address=0x680)
    frame #0: 0x0000000103cd247c Flutter`dart::Message::~Message() + 160
Flutter`dart::Message::~Message:
->  0x103cd247c <+160>: ldr    x8, [x8, #0x680]
    0x103cd2480 <+164>: ldr    x20, [x8, #0x400]
    0x103cd2484 <+168>: ldr    x21, [x19, #0x18]
    0x103cd2488 <+172>: mov    x0, x20
Target 0: (Runner) stopped.
Lost connection to device. ```

[JaffaKetchup]

Can indeed verify. However, not sure what the problem is. Interestingly, I have never seen the first error message before. My error is always about a null pointer exception?
Probably related to the poor performance in debug mode, as the app slows right down before showing this message.
Am currently looking further into it, but as release builds appear not to be affected, I'm not making this as high priority.

This won't be an issue in flutter_map, as that's this libraries ImageProvider in the first log.

[JaffaKetchup]

Full log - it's an engine crash

F/libc ( 5753): Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x304 in tid 5958 (DartWorker), pid 5753 (le.fmtc_example)
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/sdk_gphone_x86/generic_x86_arm:11/redacted'
Revision: '0'
ABI: 'x86'
Timestamp: 2022-01-21 21:32:04+0000
pid: 5753, tid: 5958, name: DartWorker >>> dev.org.fmtc.example.fmtc_example <<<
uid: 10158
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x304
Cause: null pointer dereference
eax 00000000 ebx bffdfb38 ecx a5c7c504 edx a5c7c4a8
edi b7f07510 esi ef0307c0
ebp a5c7bf98 esp a5c7bf70 eip bfc69d73
backtrace:
#00 pc 019a5d73 /data/app/~~9EOue2_aitboCcEpy_Wt4Q==/dev.org.fmtc.example.fmtc_example-3mv4MYMcILpmjNIq_LX6Sg==/base.apk!libflutter.so (offset 0x31ac000) (BuildId: 8addb1137b7230ff47ec7751e1b09b223c181acb)
#1 pc 0191fe1a /data/app/~~9EOue2_aitboCcEpy_Wt4Q==/dev.org.fmtc.example.fmtc_example-3mv4MYMcILpmjNIq_LX6Sg==/base.apk!libflutter.so (offset 0x31ac000) (BuildId: 8addb1137b7230ff47ec7751e1b09b223c181acb)
#2 pc 01923236 /data/app/~~9EOue2_aitboCcEpy_Wt4Q==/dev.org.fmtc.example.fmtc_example-3mv4MYMcILpmjNIq_LX6Sg==/base.apk!libflutter.so (offset 0x31ac000) (BuildId: 8addb1137b7230ff47ec7751e1b09b223c181acb)
#3 pc 01922f8b /data/app/~~9EOue2_aitboCcEpy_Wt4Q==/dev.org.fmtc.example.fmtc_example-3mv4MYMcILpmjNIq_LX6Sg==/base.apk!libflutter.so (offset 0x31ac000) (BuildId: 8addb1137b7230ff47ec7751e1b09b223c181acb)
#4 pc 01ac42db /data/app/~~9EOue2_aitboCcEpy_Wt4Q==/dev.org.fmtc.example.fmtc_example-3mv4MYMcILpmjNIq_LX6Sg==/base.apk!libflutter.so (offset 0x31ac000) (BuildId: 8addb1137b7230ff47ec7751e1b09b223c181acb)
#5 pc 01ac45d9 /data/app/~~9EOue2_aitboCcEpy_Wt4Q==/dev.org.fmtc.example.fmtc_example-3mv4MYMcILpmjNIq_LX6Sg==/base.apk!libflutter.so (offset 0x31ac000) (BuildId: 8addb1137b7230ff47ec7751e1b09b223c181acb)
#6 pc 01a482f1 /data/app/~~9EOue2_aitboCcEpy_Wt4Q==/dev.org.fmtc.example.fmtc_example-3mv4MYMcILpmjNIq_LX6Sg==/base.apk!libflutter.so (offset 0x31ac000) (BuildId: 8addb1137b7230ff47ec7751e1b09b223c181acb)
#7 pc 000e6974 /apex/com.android.runtime/lib/bionic/libc.so (__pthread_start(void*)+100) (BuildId: 6e3a0180fa6637b68c0d181c343e6806)
#8 pc 00078567 /apex/com.android.runtime/lib/bionic/libc.so (__start_thread+71) (BuildId: 6e3a0180fa6637b68c0d181c343e6806)

[JaffaKetchup]

Found some REALLY interesting links based on the log above:

• https://stackoverflow.com/questions/17840521/android-fatal-signal-11-sigsegv-at-0x636f7d89-code-1-how-can-it-be-tracked#:~:text=OSMDroid%20API%20for%20offline%20mapping - whilst the question is not at all related to this, they were trying to do map caching as well?
  • https://stackoverflow.com/a/70621719/11846040 - maybe it is flutter_map?
  • https://stackoverflow.com/a/54401420/11846040 - memory issues
  • https://stackoverflow.com/a/51140959/11846040 - would explain why it's only in Debug mode
  • https://stackoverflow.com/a/18645899/11846040 - but the accepted answer throws all of this out the window
• Maybe I'm calling a native method in an Isolate? I've heard this can happen.
• Crash during app startup (Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8) flutter/flutter#55051
• Crash during app startup (Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x1525cae0) flutter/flutter#55147

Don't know if this helps, but it is interesting.

Here's the Sentry issue: https://sentry.io/share/issue/97c15c7ddf6d4d38a1fdd5f653d702ad/. Hopefully I can get it to symbolise the crash.

[JaffaKetchup]

https://anonfiles.com/bbMegaD0x6/13b1dd8a-727b-ff30-47ec-7751e1b09b22_txt - full symbolicated crash log
https://sentry.io/share/issue/7182be53d8024add863cccf7609669c7/ - new Sentry issue

[JaffaKetchup]

@bmason8 & all others interested.

I've gambled on the fact that these issues are due to memory restraints, and I might be right.
With my latest AsyncMapCachingManager, I put all IO operations in separate isolates, to try to increase processing speed more. However, it appears that creating too many isolates puts too much strain on memory. I'm hoping it's a similar issue in the ImageProvider.

If this is the issue, you should be able to expect a fix by Sunday 30th at the very latest, probably sooner. If not, I have no other fallback ideas yet.

Thanks for all your support!

[bmason8]

@JaffaKetchup Thanks for the update(s)! I haven't had time to look through those links yet from your post 5 days ago but appreciate you doing all this detective work! I'll be ready to test out your next version when it's ready.

[JaffaKetchup]

@bmason8 Update much quicker than I expected:

New release v4.0.0-dev.10 has been released and should fix this issue!
Note that the recovery system has been completely rewritten but not completely re-tested. Therefore there may be bugs in the recovery system (will be fixed before release).

Please reply whether this solves the problem!
Thanks.

[bmason8]

Wow, instant improvement! No performance issues in debug anymore which is awesome!

Could you explain a little bit what you mean by the recovery system?

[JaffaKetchup]

Great to hear.

The recovery system allows a stopped bulk download to restart in the event of a crash etc.
Previously it used my own format, which was hard to read and maintain, so I switched it to a new format which is much easier to use: .ini.
I haven't yet tested whether it can be restored though, so don't count on it for now.

Apologies for all the problems caused whilst you were building your app!