[FFmpeg-devel] [PATCH] ffserver: fix memory leaks pointed out by valgrind.
nfxjfg at googlemail.com
Sat Apr 15 16:14:21 EEST 2017
On Sat, 15 Apr 2017 09:47:58 +0200
Zalewa PL <zalewapl at gmail.com> wrote:
> > The plan is that if ffserver is not fixed before the next bump, it will
> > be removed.
> ffserver has been serving our purpose in a 24/7 fashion for about 7
> years now. It will probably be serving us for the foreseeable future,
> whatever the community decides. I prefer to share any fix I make back
> with the community because allowing everyone to build on top of better
> software pays off. If the community drops the program, we most likely
> won't, even if it means being stuck with a single version for years to
> come. However, we still need to get it as stable as possible.
If your company thinks ffserver is so important, you should probably
invest work into it to fix it.
> I also admit that I'm not versed in the codebase and whatever change I
> made was based purely on valgrind's output. I understand that my patch
> in its current state is not ideal and I probably should have attempted a
> cleaner fix before submitting. I'll try to do that.
> Having stated this, let's get back to the technical topic:
> > This accesses plenty of internal fields. (Maybe did so before, but no
> > matter.)
> > So doing the freeing correctly (if even possible) would be better for
> > the survival of ffserver.
> At first I was hoping that avformat_free_context() will do the job
> nicely for me, but unfortunately there are some shared objects that get
> destroyed in this call and ffserver eventually crashes. If you run such
> ffserver build in valgrind, it will warn about "free'd memory" accesses.
Which shared objects?
> The problem seems to stem from the "COPY" done in unlayer_stream(). I
> will try to reverse this "COPY" before avformat_free_context() and see
> if it helps.
> Best regards,
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel