Pipeline leaks a lot of threads

[distinctdan]

I'm building an android app where streaming can be stopped and started repeatedly. However, I've discovered that Pipeline appears to be leaking a lot of threads after stop() is called, like 7 or 8 threads. I know android isn't officially supported, but this appears to be a bug in the native side since the android classes are just thin wrappers. Am I missing something here that I'm supposed to be cleaning up?

In this example, I'm starting and stopping the pipeline in a loop every couple of seconds to demonstrate the memory growth:

SDK version is 2.56.5

while(true) {
    delay(5000)
    
    val thread = Thread {
        val config = Config()
        config.use {
            config.disableAllStreams()
            config.enableStream(StreamType.COLOR, -1, STREAM_WIDTH, STREAM_HEIGHT, StreamFormat.ANY, 6)

            val pipeline = Pipeline()
            pipeline.use {
                pipeline.start(config)
                Thread.sleep(1000)
                pipeline.stop()
            }
        }
    }
    thread.start()
}

[MartyG-RealSense]

Hi @distinctdan If memory is being consumed then a way to combat this is to release frames, like in the Android code at #5424 (comment)

[distinctdan]

Hi MartyG, so I'm actually more concerned about the threads, although of course memory is important too. If you look in my screenshot, the top dashed line represents the active thread count. It looks like pipeline.start() spawns a bunch of threads but doesn't kill them when you call stop() or close(). For the frames, I would expect that stopping and closing the pipeline would clean up any frames in any buffers, is that not true?

[MartyG-RealSense]

Yes, frames and other resources should be released when the pipeline is closed.

I only know of one other example at #10242 where an Android user was putting the thread to sleep before the stop() command. In their particular project, they were using 1000 / 30 instead of 1000 in their thread sleep instruction.

[distinctdan]

So the sleep here is just for this example, in my real code we start the stream thread, then at some later time in the future, the user may choose to stop the stream. I can post the full code if you're interested, but I'm not sure it's relevant, so I stripped it down to just the minimal example with the pipeline start/stop/close.

Thanks for confirming that closing the pipeline should free the resources. I've tried a variety of things and haven't been able to stop it from leaking, so I'm currently being forced to abandon Pipeline and start exploring using the lower level API to connect to the sensor directly. I briefly looked at the Pipeline C++ source, I'm not a C++ expert by any means so I wasn't sure, but I did see that in src/pipeline/pipeline.cpp, in pipeline::unsafe_stop(), all the stop code is in a try catch and it's silently ignoring any errors, so I'm wondering if the stop is actually failing and it's just swallowing the error.