Application crashes if the AR activity is closed while resolving the Cloud Anchor

[grassydragon]

2021-11-22 23:42:31.755 19563-19563/com.example.virtualpresent I/native: I1122 23:42:31.755511   19563 session.cc:1619] Entering Session::Pause.
...
2021-11-22 23:42:31.760 19563-19563/com.example.virtualpresent D/ARCore-Api: ArSession_pause() -> AR_SUCCESS
2021-11-22 23:42:31.760 19563-19563/com.example.virtualpresent I/native: I1122 23:42:31.760464   19563 session_lite_c_api.cc:37] Deleting ArSession...
    
    
    --------- beginning of crash
2021-11-22 23:42:31.778 19563-19738/com.example.virtualpresent A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7700000018 in tid 19738 (Thread-39), pid 19563 (main)

[doranteseduardo]

That's exactly the issue I have in the react-native-sceneform repo.

It doesn't happen with ARCore so it must be Sceneform specific.

[ThomasGorisse]

Isn't it a normal case? Shouldn't you cancel resolving if the session is closed?

[grassydragon]

I haven't found any documentation about that but in the ARCore sample Cloud Anchor application the anchor is detached in onDestroy: https://github.com/google-ar/arcore-android-sdk/blob/06573b8e1f3ef336084c9a0ee627937246896ea0/samples/cloud_anchor_java/app/src/main/java/com/google/ar/core/examples/java/cloudanchor/CloudAnchorActivity.java#L188

[grassydragon]

I've fixed the problem by detaching the anchor before calling super.onDestroy:

override fun onDestroy() {
    arFragment.apply {
        setOnSessionConfigurationListener(null)
        setOnViewCreatedListener(null)
        arSceneView.scene.removeOnUpdateListener(this@SearchPresentActivity)
    }

    if (viewModel.state.value == SearchPresentState.ResolvingCloudAnchor) {
        Log.d(TAG, "Detach Cloud Anchor")
        anchor.detach()
    }

    super.onDestroy()
}

However, my application with AR annotations that still uses Sceneform 1.18.10 works well without that change.

[ThomasGorisse]

However, my application with AR annotations that still uses Sceneform 1.18.10 works well without that change.

That must be related to the solved session cleaning after onDestroy introduced on 1.19.0 from what I remember. But that also can be due to some big try catch remove around the frame callback. (Look at the one on the ARCore sample)

I've fixed the problem by detaching the anchor before calling super.onDestroy:

Can you confirm that Sceneform doesn't have any knowledge of the existence of your Anchor until it's resolved? If that is the case, we cannot do anything around it since we cannot detach an Anchor we don't know (Not on the Scene) I didn't had a look at the cloud anchors yet. That's a big update missing part in Sceneform.

Question: Is it a Sceneform or ARCore issue?

[grassydragon]

Can you confirm that Sceneform doesn't have any knowledge of the existence of your Anchor until it's resolved?

Yes, I create the AnchorNode after the anchor is resolved.

Question: Is it a Sceneform or ARCore issue?

Since there is no documentation about stopping resolving the anchor I expect ARCore to clean up the connection and not to fail with a native error.

[ThomasGorisse]

@devbridie Is there any way to stop the anchor resolving or just to make it not crashing after a session stopped?

Do you want us to create an issue on the ARCore repo?

[grassydragon]

I now see the difference. In the previous application I created the AnchorNode right away. Let me experiment with that.

[devbridie]

This is definitely an ARCore bug; could you attach the native stacktrace? It should appear just after the message you posted and starts with:

A/DEBUG: backtrace:
A/DEBUG:       #00 pc 00000000000...

[grassydragon]

2021-11-23 20:21:20.595 14993-14993/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG: Build fingerprint: 'google/sargo/sargo:12/SP1A.211105.002.A1/7807550:user/release-keys'
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG: Revision: 'MP1.0'
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG: ABI: 'arm64'
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG: Timestamp: 2021-11-23 20:21:19.532559163+0300
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG: Process uptime: 0s
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG: Cmdline: com.example.virtualpresent
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG: pid: 14489, tid: 14872, name: Thread-47  >>> com.example.virtualpresent <<<
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG: uid: 10362
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7400000018
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:     x0  000000760ebcef50  x1  000000774ed5ee00  x2  0000000000000000  x3  00000074a33a38d0
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:     x4  0000000000000000  x5  01ec6fb3921c9494  x6  6f7073746f68390a  x7  6235363332382f74
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:     x8  0000007400000000  x9  00000074c3dc1b54  x10 000000009b4e59d1  x11 00000000cec0b780
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:     x12 0000ffff00000eff  x13 0000000006e30d5d  x14 0000000000004104  x15 0000000000000080
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:     x16 00000074c418be40  x17 000000783f913c78  x18 000000749e2a0000  x19 00000075fec15b58
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:     x20 000000766ebf9e90  x21 000000760ebcef50  x22 00000075fec15b40  x23 000000774ed5ee00
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:     x24 0000000000004104  x25 00000075cec134e0  x26 00000075cec134f8  x27 000000759ebea0b0
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:     x28 ff01010101010101  x29 00fefefefefefefe
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:     lr  00000074c3dc21a0  sp  00000074a33a3740  pc  00000074c3dc21d8  pst 0000000060000000
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG: backtrace:
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:       #00 pc 0000000001b4a1d8  /data/app/~~AhHs4FjAZQMrKolm0zO6tw==/com.google.ar.core-bpNacTQ099ryCxeBGPEtOg==/base.apk!libarcore_c.so (BuildId: cf9926e6d37165f45cff881447f1c714)
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:       #01 pc 0000000001b4efe4  /data/app/~~AhHs4FjAZQMrKolm0zO6tw==/com.google.ar.core-bpNacTQ099ryCxeBGPEtOg==/base.apk!libarcore_c.so (BuildId: cf9926e6d37165f45cff881447f1c714)
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:       #02 pc 0000000001b562f8  /data/app/~~AhHs4FjAZQMrKolm0zO6tw==/com.google.ar.core-bpNacTQ099ryCxeBGPEtOg==/base.apk!libarcore_c.so (BuildId: cf9926e6d37165f45cff881447f1c714)
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:       #03 pc 00000000010b94b4  /data/app/~~AhHs4FjAZQMrKolm0zO6tw==/com.google.ar.core-bpNacTQ099ryCxeBGPEtOg==/base.apk!libarcore_c.so (BuildId: cf9926e6d37165f45cff881447f1c714)
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:       #04 pc 00000000010c8ff8  /data/app/~~AhHs4FjAZQMrKolm0zO6tw==/com.google.ar.core-bpNacTQ099ryCxeBGPEtOg==/base.apk!libarcore_c.so (BuildId: cf9926e6d37165f45cff881447f1c714)
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:       #05 pc 00000000010c5874  /data/app/~~AhHs4FjAZQMrKolm0zO6tw==/com.google.ar.core-bpNacTQ099ryCxeBGPEtOg==/base.apk!libarcore_c.so (BuildId: cf9926e6d37165f45cff881447f1c714)
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:       #06 pc 00000000000b1910  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+264) (BuildId: ba489d4985c0cf173209da67405662f9)
2021-11-23 20:21:20.595 14993-14993/? A/DEBUG:       #07 pc 00000000000513f0  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: ba489d4985c0cf173209da67405662f9)

[github-actions[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please feel free to create a new issue with up-to-date information.