Memory leak

[onthegit]

Memory leak

[RSWilli]

Ah interesting, I was looking at the code for a while and wondered where something like this could occur.

The created C buffers are unrefed here and the wrapBuffer function you mention only performs a golang allocation.

The NewBufferFromBytes function seems to correctly unref all created C objects.

Ah but I see a lonely Ref() call in PushBuffer (aka no unref), that may be the source of your issue.

I even think that there shouldn't be a Ref() call in the first place, since gst_app_src_push_buffer takes ownership of the buffer.

@onthegit could you try it out and post your feedback, or provide me with a minimal setup that I can run and profile?

[RSWilli]

@tinyzimmer what do you think?

[tinyzimmer]

@tinyzimmer what do you think?

This isn't the first memory leak fought on those methods. The last one dates back to gstreamer 1.18.

I'll have to look more closely to see but last I recall that buffer is just populated with a memset from the original.

Debugging memory leaks in CGO is a particular pain. At the time a heavily tuned valgrind helped me track it down.

[onthegit]

Hello, thanks for your replies,
I tried replacing NewBufferFromBytes with

p.src.PushBuffer(gst.NewBufferFull(gst.MemoryFlagReadOnly, cp, int64(len(cp)), 0, int64(len(cp)), func() { fmt.Println("closed") }))

and the memory leak is even bigger. The function does print when the buffer is closed

[onthegit]

@RSWilli I tried removing Ref() and the memory still kept growing.

[onthegit]

It appears the there is memory leak in mp4mux element. Valgrind shows that there are a lot of allocations in gstreamer isomp4 library. The mp4mux element was set like this:

	if err = mux.SetProperty("faststart", true); err != nil {
		return nil, errors.New("could not set property: faststart " + err.Error())
	}

	if err = mux.SetProperty("fragment-duration", uint(60)); err != nil {
		return nil, errors.New("could not set property: fragment-duration " + err.Error())
	}

	mux.SetArg("fragment-mode", "first-moov-then-finalise")

Once they were removed, the leak was gone. I am still testing whether it will leak again but so far have not seen major increases in memory usage. Will test further.
So this might be a problem with the mp4mux element, and maybe someone with permissions at gstreamer repo can report the issue.

Worth mentioning is that there was no leak (from my short testing) when the pipeline elements (except src element) were replaced with fakesink

[RSWilli]

You could talk to the gstreamer devs on the gstreamer IRC channel.

maybe someone with permissions at gstreamer repo can report the issue

You can create an account by yourself and get verified to report the issue, though.