Memory leak when using Play?

I noticed when using the Play example, each "Play::new" will cause a memory leak. Not sure why but my guess is that all resources aren't properly released upon drop.

Here is an example to demostrate it. It requires https://docs.rs/memory-stats/latest/memory_stats/ in order to print the memory usage. It can be removed if you want to check the usage externally.

use gstreamer_play::{gst, Play, PlayMessage, PlayVideoRenderer};
use std::path::Path;

fn play_video(play: &Play, uri: &str) {
    // Tell the player what uri to play.
    play.set_uri(Some(uri));
    play.play();
    let mut result = Ok(());

    for msg in play.message_bus().iter_timed(gst::ClockTime::NONE) {
        match PlayMessage::parse(&msg) {
            Ok(PlayMessage::EndOfStream) => {
                play.stop();
                break;
            }
            Ok(PlayMessage::Error { error, details: _ }) => {
                result = Err(error);
                play.stop();
                break;
            }
            Ok(_) => {}
            Err(_) => unreachable!(),
        }
    }
    result.unwrap()
}

fn main() {
    gst::init().unwrap();
    let path = std::env::args().skip(1).next().unwrap();
    let url = url::Url::from_file_path(Path::new(&path).canonicalize().unwrap()).unwrap();
    loop {        
        let play = Play::new(None::<PlayVideoRenderer>);
        play.set_audio_track_enabled(false);
        play_video(&play, url.as_str());
        let stats = memory_stats::memory_stats().unwrap();
        println!("{} Mb", stats.physical_mem / 1024 / 1024);
    }
}

Just give some short video as an argument and let it loop a bit and the memory usage should increase on every loop.

EDIT:

I noticed that even if you only call play.set_uri(..) there is a small memory leak.

In this example, you will considered leaked the data created for the GLib type system, which is indeed never freed, but that is not a bug. I'd suggest to use valgrind and all the suppression files, or use the leak tracer (object only) instead.

closed

But how are you supposed to not leak, or at least accumulate the data not being freed?

If memory usage is increasing every loop then this is a different problem than what @ndufresne said. The statically allocated memory for GLib/GObject would stay the same after the first iteration.

Please run in a proper memory profiler to get some more hints about what is actually happening there. valgrind can tell you about actual leaks (after everything is dropped and you called gst::deinit()), heaptrack or massif could tell you about memory accumulating somewhere (and where).

reopened

added Awaiting feedback label

You might also run into memory fragmentation (in that case all the tools above would not show any increase but the RSS of the process would increase), and setting G_SLICE=always-malloc and using a recent glibc (not glib!), or using a different allocator in place of malloc (tcmalloc, jemalloc, ...) should improve that situation.

Here is a valgrind report. This is after running 10 loops and not playing but only using set_uri, and after the loops i call gst::deinit().

Error leaked 4.1 kiB in 10 blocks
        Info at calloc
             at calloc (rtld-malloc.h:44)
             at allocate_dtv (dl-tls.c:375)
             at _dl_allocate_tls (dl-tls.c:634)
             at allocate_stack (allocatestack.c:430)
             at pthread_create@@GLIBC_2.34 (pthread_create.c:647)
             at unknown
             at g_thread_new
             at unknown
             at unknown
             at g_object_new_with_properties
             at g_object_new
             at gst_play_new
             at gstreamer_play::auto::play::Play::new (play.rs:31)
             at play::main (play.rs:43)
       Error leaked 16.0 kiB in 1 block
        Info at malloc
             at g_malloc
             at unknown
             at unknown
             at call_init.part.0 (dl-init.c:70)
             at call_init (dl-init.c:33)
             at _dl_init (dl-init.c:117)
             at unknown
             at unknown
             at unknown
             at unknown
     Summary Leaked 20.1 kiB total

You'll have to install debug symbols to get more useful information, but these are all one-time allocations from what I can see.

Okay the one above can be ignored, ironically the memory_stats had a leak as well -_-. So set_uri does Not leak it seems.

But for some reason i get Segmentation fault now after the run ends. I basically got it the same as the example play.rs now, no matter if i run once or multiple times i get that error. So must have messed something up, will report back once i got it solved and can get a valgrind report on the actual play memory leak.

Can you get a backtrace (of all threads) with gdb when it crashes?

How would i go about doing that? I can debug it but not sure how to get a backtrace.

EDIT:

It seems to happen when breaking at PlayMessage::EndOfStream. If i just stop the player and then break at PlayMessage::StateChanged (if state is Stopped) it doesn't cause a Segmentation fault oddly enough. Though that probably doesn't help much.

EDIT 2:

Okay it seems the memory leak triggers if you break on PlayMessage::EndOfStream (and it will cause Segmentation fault when the application exits i think. Really odd..

EDIT 3:

Segmentation fault does not appear in a separate virtual ubuntu. So it might be a WSL2 issue perhaps, though the memory leak occurs in when breaking at EndOfStream, will try bring a valgrind report from it.

When running Valgrind it prints an xml instead of the normal output. not sure how to save that to a file though.

Copy&paste the output here, or redirect it to a file

output.gz

This is the output, and here is the source code, it's was run on Ubuntu WSL2.

use gstreamer_play::{gst, Play, PlayMessage, PlayState, PlayVideoRenderer};
use std::env;


fn main_loop(uri: &str) {
    gst::init().unwrap();

    let play = Play::new(None::<PlayVideoRenderer>);
    play.set_uri(Some(uri));
    play.set_audio_track_enabled(false);
    play.play();

    let mut result = Ok(());
    for msg in play.message_bus().iter_timed(gst::ClockTime::NONE) {
        match PlayMessage::parse(&msg) {
            Ok(PlayMessage::EndOfStream) => {
                play.stop();
                break;
            }
            Ok(PlayMessage::StateChanged { state }) => {
                if state == PlayState::Stopped {
                    break;
                }
            }
            Ok(PlayMessage::Error { error, details: _ }) => {
                println!("err");
                result = Err(error);
                // play.stop();
                break;
            }
            Ok(l) => {}
            Err(_) => unreachable!(),
        }
    }

    result.unwrap()
}

fn main() {
    let args: Vec<_> = env::args().collect();
    let uri: &str = if args.len() == 2 {
        args[1].as_ref()
    } else {
        println!("Usage: play uri");
        // std::process::exit(-1)
        "./images/2023-09-08.mkv"
    };

    let url = url::Url::from_file_path(std::path::Path::new(uri).canonicalize().unwrap()).unwrap();
    // println!("{}", url);
    for _ in 0..2 {
        let url = url.to_string();
        main_loop(&url);
        // let stats = memory_stats::memory_stats().unwrap();
        // println!("{}", stats.virtual_mem);
    }
}

mentioned in commit slomo/gstreamer-rs@4cf4f229

mentioned in merge request !1346 (merged)

This is most likely solved by !1346 (merged). See also #489 (closed) and gstreamer#3107 (closed)

Please re-open if this is still a problem afterwards.

mentioned in commit slomo/gstreamer-rs@c4413f1d

closed with commit c4413f1d

I tried using the latest git version, but it seems to still crash on exit.