Filament crashes at onDestroy

[kulikov0]

Steps to reproduce:

1. Run ar-augmented-image sample
2. Press back button

Result:

Filament E Precondition
in destroy:1262
reason: destroying MaterialInstance "flat" which is still in use by Renderable (entity=5, instance=2, index=0)
Filament E
libc A Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 2824 (raugmentedimage), pid 2824 (raugmentedimage)
DEBUG A pid: 2824, tid: 2824, name: raugmentedimage >>> io.github.sceneview.sample.araugmentedimage <<<
DEBUG A #1 pc 0000000000220050 /data/app/io.github.sceneview.sample.araugmentedimage-rJYotmmebeEpZ1nE-s2Zeg==/base.apk!libfilament-jni.so (offset 0xd50000) (utils::TPanicutils::PreconditionPanic::panic(char const*, char const*, int, char const*, std::__ndk1::basic_string<char, std::__ndk1::char_traits, std::__ndk1::allocator>)+176) (BuildId: d5861ae549ccbba9b42c018622ea03a688c32f73)
InputDispatcher E channel '6166e79 io.github.sceneview.sample.araugmentedimage/io.github.sceneview.sample.araugmentedimage.Activity (server)' ~ Channel is unrecoverably broken and will be disposed!

[qstuff]

I also encounter a native crash onDestroy()
I'm using an own implementation with ExoPlayer similar to the ar-augmented-image example inside a fragment and got the following Error log:

E0000 00:00:1762162218.927547 10344 scheduler.cc:281] INTERNAL: RET_CHECK failure (third_party/mediapipe/framework/scheduler.cc:281) state_ != STATE_NOT_STARTED (0 vs. 0)
E0000 00:00:1762162218.927665 10344 normal_detector_cpu.cc:235] Error graph_->WaitUntilIdle():INTERNAL: RET_CHECK failure (third_party/mediapipe/framework/scheduler.cc:281) state_ != STATE_NOT_STARTED (0 vs. 0)
=== Source Location Trace: ===
third_party/mediapipe/framework/scheduler.cc:281
third_party/mediapipe/framework/calculator_graph.cc:955
Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 10344 (memorylanes.dev), pid 10344 (memorylanes.dev)
W0000 00:00:1762162219.623923 10896 statistics.cc:265] Reset statistics may cause dangling handle issue

in the fragments onDestroyView() i'm calling this:

override fun onDestroyView() {

        exoPlayer.pause()
        exoPlayer.clearVideoSurface()
        exoPlayer.stop()
        exoPlayer.release()

        videoMaterial.destroy()

        sceneView?.destroy()
}

Thankful for any hints

[qstuff]

Quick update: Setting the ExoPlayer instance to null when the Fragment is destroyed fixed my problem. So i think this would also fix the sample apps issue.

override fun onDestroyView() {

        exoPlayer.pause()
        exoPlayer.clearVideoSurface()
        exoPlayer.stop()
        exoPlayer.release()

        exoPlayer = null

        videoMaterial.destroy()

        sceneView?.destroy()
}

[qstuff]

Unfortunately this was not enough... I had some runs without crash but with another video it came back :(

[qstuff]

Finally it really works in my environment when i only clean up the exoplayer:

exoPlayer?.apply {
    stop()
    clearVideoSurface()
    release()
}
exoPlayer = null

And do not override the "destroy()" method of the ExoPlayerVideoNode:PlaneNode.
Put this cleanup code in an own function and call it in your View's onDestroy() function.
Any attempt to do so results in a native crash because of a "double free".
Also do not call videoMaterial.destroy() nor sceneView.destroy().

Everything inside the sceneView is cleaned up by the framework

[kulikov0]

I found a hack: if you downgrade the filament version to 1.57.1, you will still have an error in the logs:

Filament                 E  destroying material "flat" but 0 instances still alive.destroying material "depth" but 0 instances still alive.destroying material "AR Core Plane Material" but 0 instances still alive.destroying MaterialInstance "View" which is still in use by Renderable (entity=1307, instance=2, index=0)

Filament                 E  destroying MaterialInstance "View" which is still in use by Renderable (entity=1308, instance=1, index=0)

but at least it does not crash and supports 16kb page size.

[ydhnwb]

I think this is valid issue, it crash when user click back, even with minimal implementation like in example

[ydhnwb]

I found a hack: if you downgrade the filament version to 1.57.1, you will still have an error in the logs:

Filament                 E  destroying material "flat" but 0 instances still alive.destroying material "depth" but 0 instances still alive.destroying material "AR Core Plane Material" but 0 instances still alive.destroying MaterialInstance "View" which is still in use by Renderable (entity=1307, instance=2, index=0)

Filament                 E  destroying MaterialInstance "View" which is still in use by Renderable (entity=1308, instance=1, index=0)

but at least it does not crash and supports 16kb page size.

How to do it?

[ydhnwb]

My workaround is to make sure the Sceneview is destroyed on click back.

var cleanupTrigger by remember { mutableStateOf(0) }
var sceneViewRef by remember { mutableStateOf<SceneView?>(null) }
val nav = LocalNavigator.currentOrThrow // voyager nav library

BackHandler {
   cleanupTrigger++ // force new key every time
}

LaunchedEffect(cleanupTrigger) {
    if (cleanupTrigger > 0) {
        try {
            // give UI a short frame to finish transition
            withFrameNanos { }
            sceneViewRef?.destroy()
            nav.pop()
        } catch (e: Throwable) {
            Log.w("SceneCleanup", "Ignored SceneView cleanup error: ${e.message}")
        }
    }
}

 Scene(
    onViewCreated = {
        sceneViewRef = this
    },

it's ugly and seems hacky, but this is the only workaround that works for me

[ThomasGorisse]

Fixed in v2.3.1