[MPlayer-dev-eng] [QUESTION] Stabilizing MPlayer

[Arpi]

Hi,

> I knew it was a fake, but I was also quite shocked that somebody had the idea 
> to do this ...
I felt the same.

> - how to find memory holes/leaks ?
> 	+ there was software mentioned, but I can't find that thread anymore

valgrind - it's the best for memleaks, but it doesn't like mmx etc so you
have to recompile code with all cpu optim disabled.
once a few months ago i've done sone valgrind'ing and fixed few big leaks
(it found that avi files' index was read twice :)) but then it got very
boring to hunt for small leaks, and i couldn't fix the demux_ogg.c leak, it
leaked ~600kbyte in libogg and i couldn't fix it (when i called the lib's
destroy() it crashed, when manualy free()'d stuff also crashed)
[hint: someone with libogg/vorbis knowledge should look at it]

valgrind has the big advantage that it can make difference between leaked
memory and memory not free'd. (it somehow traces pointers in code or what)

since mplayer was designed for single file playback, the whole core code
is made with 'the OS will free() them at exit' in mind, and i don't think
it's bad or we should add tons of free() calls everywhere.

(note that non-free'd memory just leaks memory, but a free() at wrong place
causes crash somewhere else)

njamd - another memory debugger, it's good for finding free() without malloc(),
and any kind of memory corruptions. it overallocates memory blocks, and puts
marks over the returned range, so it will even notice if the app writes a
single byte too much there.

> - are there most often made common mistakes + 10l's that can "easily" be 
> discovered by just scanning the code (painful reading, but could be worth it)
> 	+ any website/url ?
it's called code autit... and really painful.
i'm trying to do it at each commit, by reading the diffs carefully, but bugs
just go in sometimes.

> - what about our bug-tracking system ? Does it sleep or is it ready for 
> production-use ...
it is ready for testing. i got no reports, nor that it works, not that it
crashes, not that it sucks, not that sth is missing.
but if we need modifications of database structure (by adding new fields,
etc) then we need to zero out database so we should do any mods before
starting the production use.

> - Are there other open and known BUGS not mentioned in TODO ?
sure. just browse -users :)
anywaw someone should collect real (verify!) bugreports from maillists and
put them to TODO or maybe better: BUGS.

> - Are there unclean things that need to be partly rerwitten (only small 
> things) to make it more stable ... ?
half of the code... esp. demuxers and most of the libvo drivers.
for example there are 33 vo drivers, but only the major ones
(x11,xv,xmga,mga,fbdev,vesa,svga,xvidix?) are more or less maintained,
updated to api changes, the rest is just unchanged since ages.
also these few are outdated to teh libvo API, most doesn't work with
-fixed-vo, most have problems with fullscreen switching, panscan, xinerama
etc.  they are small independent code piexes, nice starting point, but
painful to test. and also requires deep knowledge of libvo api including the
hacks & tricks used.

> - How can we assure that some part of code is "stable" ?
unchanged since few months and no related bugreports :)

> 	+ yes, I'm talking about some kind of Quality-Assurance-Management
:)

> 	+ is there perhaps a certain cvs-flag that could tell that this code has been 
> checked and is "clean" ... ?
you can 'tag' them as 'stable' or sth.
but imho it has no sense.

> - Are there other things except those mentioned above needed to stabilize 
> mplayer ?
fixing the known bugs?
heavy testing on mphq samples/ dir ?
heavy testing by users ? (==release :))

> And last: 
> 
> Are others willing to help stabilizing it and really look through old code / 
> find things that probably need to be redesigned after 0.90 and help hunting 
> bugs ?

please no more redesign to 0.90. i really want to release rc3 asap and then
0.90 final asap. do not delay it more (redesigns delay releases by at least 1
month)

we should concentrate on bugs now, and get back the good old rock solid mplayer.

i'm asking everyday the question on irc 'rc3 today?' but the answer is
always no, followed by long list of serious bugs... and then i see more bugs
on -users, so i go watching a film instead... and i find more bugs then. :(

> And nearly only doing this and not adding soooooooo much features now ...

we shouldn't add features at all, only exceptions are independent modules,
like new vo_* or new codec or new demuxer, since they don't affect the rest
of the code. the other exception is the new libaf, since it's unfinished and
we should allow it developing.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu