[MPlayer-users] Re: memleak in cvs

[Julien WAJSBERG]

On 21 Aug 2002, Ed Sweetman wrote:

> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Read it.  I posted all the relevent information it said i should.
>
> mplayer -v
> MPlayer CVS-020819-18:20-2.95.4
Better do :
mplayer -v file
to get lots of useful output...

>
> it's the latest cvs (despite the doc updates of late) of mplayer as of
> yesterday.
>
>
> It does seem to only show up when using the gui.  But are you saying
> that the gui is not part of mplayer?
>
> I find it funny that you consider the gui not a part of mplayer.  there
> are several audio outputs and video outputs and now there are two user
> interfaces, some may be experimental or buggy but it's still mplayer.
> It's obvious that the gui is now an mplayer feature just as much as your
> different audio and video interfaces are, this is just a different user
> interface.  There have to be some core developers using the gui in order
> to develop it and it's obvious that it is getting actively developed and
> core developers do best to compile mplayer with as many of the features
> their project has that they can and test them so obvious situations like
> this get caught before going out cvs or at least not very long in cvs.
>
> I could be wrong though and if none of the core developers consider the
> gui part of mplayer to be part of mplayer (and the site says it is) then
> maybe they should take it out and the gui should be developed as a
> frontend like every other project that doesn't want to deal with a gui
> has.  someone else then is responsible for the gui and gui problems are
> completely separate from the backend program.  In mplayer's case the gui
> is not simply a frontend so it is mplayer.   And the memory usage i'm
> seeing must be caused by gui hooks because i dont see how gtk code can
> be consuming the memory as video is playing.  I work with gtk and i dont
> see mplayer doing anything that could be doing that.  But because the
> gui is a part of mplayer it's unclear as to if code inside gui hooks
> where the gtk code is attached to the player or in code for gtk use that
> is going insane (file progress info etc?).  It doesn't pay to ignore
> huge new parts of code to your project as a developer.

It's just to see where the bug comes from...
If the bug is still here without the gui, we'll know that it comes from
the core mplayer.
But if it's not here anymore, we'll know that the bug is in the gui code
:)

-- 
Flash

'divide to conquer' ?