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

Using mapbox flutter and then the app crashed, #257

Closed
gnuHnauT1 opened this issue Jun 22, 2023 · 5 comments
Closed

Using mapbox flutter and then the app crashed, #257

gnuHnauT1 opened this issue Jun 22, 2023 · 5 comments

Comments

@gnuHnauT1
Copy link

When i click on each element of the list containing the fillLayers and it switches to the map screen it gives the error below and then it crashes the app
(14224): Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 14619 (Thread-12), pid 14224 (com.nylo.dev)
[+1303 ms] *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
[ ] Build fingerprint: 'google/sdk_gphone64_x86_64/emu64x:13/TE1A.220922.021/9526604:userdebug/dev-keys'
[ ] Revision: '0'
[ ] ABI: 'x86_64'
[ ] Timestamp: 2023-06-22 09:23:05.039232600+0700
[ ] Process uptime: 111s
[ ] Cmdline: com.nylo.dev
[ ] pid: 14224, tid: 14619, name: Thread-12 >>> com.nylo.dev <<<
[ ] uid: 10159
[ ] signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000000
[ ] Cause: null pointer dereference
[ ] rax 0000000000000000 rbx 00007cf19df5e710 rcx 0000000000000001 rdx 0000000000000001
[ ] r8 00007cf19df5e628 r9 0000000000000001 r10 000000000010142c r11 00007cf4bae5af58
[ ] r12 00007cf1beeb2434 r13 00007cf19df5e890 r14 0000000000000001 r15 00007cf2e4080598
[ ] rdi 0000000000000000 rsi 0000000000000000
[ ] rbp 0000000000000000 rsp 00007cf19df5e6c0 rip 00007cf1a677ecc9
[ ] backtrace:
[ ] #00 pc 000000000012dcc9 /data/app/~~nslCNlL1x7DQVLUAG1TBXQ==/com.nylo.dev-qYYnHqqfaEbr2a2-bpPnhg==/lib/x86_64/libmapbox-gl.so
(BuildId: 2b1b382e74e191d84e840b9f99f12d3b2b84506e)
[ ] #1 pc 000000000012dbf4 /data/app/~~nslCNlL1x7DQVLUAG1TBXQ==/com.nylo.dev-qYYnHqqfaEbr2a2-bpPnhg==/lib/x86_64/libmapbox-gl.so
(BuildId: 2b1b382e74e191d84e840b9f99f12d3b2b84506e)
[ ] #2 pc 00000000000ac89e /data/app/~~nslCNlL1x7DQVLUAG1TBXQ==/com.nylo.dev-qYYnHqqfaEbr2a2-bpPnhg==/lib/x86_64/libmapbox-gl.so
(BuildId: 2b1b382e74e191d84e840b9f99f12d3b2b84506e)
[ ] #3 pc 000000000037d70b /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+219) (BuildId:
44bc52550248fc712a381bef164b75c7)
[ ] #4 pc 0000000000369aed /apex/com.android.art/lib64/libart.so (nterp_helper+3837) (BuildId: 44bc52550248fc712a381bef164b75c7)
[ ] #5 pc 0000000000428434 [anon:dalvik-classes.dex extracted in memory from
/data/app/~~nslCNlL1x7DQVLUAG1TBXQ==/com.nylo.dev-qYYnHqqfaEbr2a2-bpPnhg==/base.apk]
(com.mapbox.mapboxsdk.maps.renderer.MapRenderer.onDrawFrame+12)
[ ] #6 pc 0000000000369a88 /apex/com.android.art/lib64/libart.so (nterp_helper+3736) (BuildId: 44bc52550248fc712a381bef164b75c7)
[ ] #7 pc 000000000042b8f8 [anon:dalvik-classes.dex extracted in memory from
/data/app/~~nslCNlL1x7DQVLUAG1TBXQ==/com.nylo.dev-qYYnHqqfaEbr2a2-bpPnhg==/base.apk]

@JulianBissekkou
Copy link
Collaborator

This is a known issue. The maplibre team introduced useDelayedDisposal which should decrease the possibility that this issue happens.
However it doesn't fix the issue which is why the plugin is not usable (for us) on android at the moment.

@JulianBissekkou
Copy link
Collaborator

See #182

@JulianBissekkou
Copy link
Collaborator

@gnuHnauT1
Can you integrate the branch tappeddev:182-disposal-null-ref-crash and see if it works?

@JulianBissekkou
Copy link
Collaborator

@gnuHnauT1
If you need help testing this fix then let me know :)

@JulianBissekkou
Copy link
Collaborator

Closing this since its a duplicate of #182

JulianBissekkou added a commit that referenced this issue Jul 4, 2023
This PR should fix the crash as described in #182  and #257 
The status is still in draft because I would like to get feedback from
android devs of maplibre-gl-native.

### Problem
The crash started to occure with flutter 3.x and after some
investigations we were able to detect the exact change that broke it.
See flutter/flutter#107297 or
flutter/flutter#107297 (comment)
for details.

The engine change in
flutter/engine@8dc7cd1
is not calling `removeView` in all cases which might be the reason why
this issue is happening.
I digged into the framework and saw that `removeView` will trigger
`onDetachedFromWindow` in the subviews. This is important since once of
the subviews is `TextureView` which destorys the surface texture:


Here is `TextureView.onDeatachedFromWindowInternal`
```java
    @OverRide
    @UnsupportedAppUsage(maxTargetSdk = Build.VERSION_CODES.R, trackingBug = 170729553)
    protected void onDetachedFromWindowInternal() {
        destroyHardwareLayer();
        releaseSurfaceTexture();
        super.onDetachedFromWindowInternal();
    }
```

My guess: If this is not called we might still draw onto a surface which
triggers the crash.

### The fix
If my assumptions are correct then this should be fixed in the engine
and not in the libraries that need a platform view. You can find the
workaround in this PR. We simply create a view container that calls
`removeView` to trigger the `onDetachedFromWindow`.
We tested this in an example app with success and also in some of our
internal projects.

Please give some feedback if my assumptions are correct. Thanks!

---------

Co-authored-by: Julian Bissekkou <[email protected]>
Co-authored-by: Stefan Schaller <[email protected]>
JanikoNaber pushed a commit to JanikoNaber/flutter-maplibre-gl that referenced this issue Aug 23, 2023
This PR should fix the crash as described in maplibre#182  and maplibre#257 
The status is still in draft because I would like to get feedback from
android devs of maplibre-gl-native.

### Problem
The crash started to occure with flutter 3.x and after some
investigations we were able to detect the exact change that broke it.
See flutter/flutter#107297 or
flutter/flutter#107297 (comment)
for details.

The engine change in
flutter/engine@8dc7cd1
is not calling `removeView` in all cases which might be the reason why
this issue is happening.
I digged into the framework and saw that `removeView` will trigger
`onDetachedFromWindow` in the subviews. This is important since once of
the subviews is `TextureView` which destorys the surface texture:


Here is `TextureView.onDeatachedFromWindowInternal`
```java
    @OverRide
    @UnsupportedAppUsage(maxTargetSdk = Build.VERSION_CODES.R, trackingBug = 170729553)
    protected void onDetachedFromWindowInternal() {
        destroyHardwareLayer();
        releaseSurfaceTexture();
        super.onDetachedFromWindowInternal();
    }
```

My guess: If this is not called we might still draw onto a surface which
triggers the crash.

### The fix
If my assumptions are correct then this should be fixed in the engine
and not in the libraries that need a platform view. You can find the
workaround in this PR. We simply create a view container that calls
`removeView` to trigger the `onDetachedFromWindow`.
We tested this in an example app with success and also in some of our
internal projects.

Please give some feedback if my assumptions are correct. Thanks!

---------

Co-authored-by: Julian Bissekkou <[email protected]>
Co-authored-by: Stefan Schaller <[email protected]>
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

No branches or pull requests

2 participants