rc4? Re: [MPlayer-dev-eng] TODO for release? bugs status...

[Fabien Tassin]

According to Filip Kalinski:
> > 
> > I reported this and just asked to revert this two line patch that fixed
> > nothing at all but caused troubles, at least to me.
> > I tried to find a way to avoid the reported (not by me) segv but I
> > never experienced it in the past, not even now. I've spent some time
> > in the code and found nothing, except that checking for NULL to trigger
> > vesa_term() is really wrong (perhaps not 10l but at least 2l). From my
> > understanding of vo_vesa.c::uninit() and linux/vbelib.c::vbeSaveState(),
> > it is wrong to test init_state to trigger vesa_term() as there are plenty
> > of good reasons to have it NULL even if vesa mode was successfully
> > initialized and used. I suggest to use the returned value of vbeSaveState()
> > instead.
> > 
> > I'd be curious to see the backtrace of the segv that this patch was
> > supposed to fix. If someone could provide it to me, I'd be happy to
> > work on a patch.
> > 
> > BTW, if you are in a hurry for 0.90, plz revert as I did myself.
> > 
> 
> (run when in X)
> sudo ./mplayer ~/movies/Megaus.mpg -vo vesa >.log 2>&1

hmm, I never uses vesa while in X. I tried a long time ago and it fucked
my X in return (leaving me with some blinking ascii chars in text mode)
and with no way to get video back without killing X, which I usually only
do a few times per year to upgrade the kernel or some HW.
I'm now used to run mplayer with xv or xvidix while in X and I swap to
vesa in console when I want TV-OUT.

BTW, I now understand the possible sig-fault.
 
> And without patch there is (of course :-) SIGSEV

Ok ok. You patch protects from something but hides too much code that
is needed. could you show us a backtrace ? unless Arpi fixes it in the
meantime :)

/Fabien