rc4? Re: [MPlayer-dev-eng] TODO for release? bugs status...
Fabien Tassin
fta+mplayer at sofaraway.org
Thu Jan 30 01:53:13 CET 2003
According to Arpi:
>
> int vbeRestoreState(void *data)
> {
> struct LRMI_regs r;
> int retval;
> memset(&r,0,sizeof(struct LRMI_regs));
> r.eax = 0x4f04;
> r.edx = 0x02;
> r.ecx = 0x0f;
> r.es = VirtToPhysSeg(data);
> r.ebx = VirtToPhysOff(data);
> retval = VBE_LRMI_int(0x10,&r);
> LRMI_free_real(data);
> if(!retval) return VBE_VM86_FAIL;
> retval = r.eax & 0xffff;
> if(retval == 0x4f) retval = VBE_OK;
> return retval;
> }
>
> so, if i understand right, init_state==NULL will cause sig11 in
> vbeRestoreState().
where ? Even if data == NULL, I can't find any problem in vbeRestoreState()
as data is never dereferenced nor freed. I just traced it several times
without a single problem. [ and no, LRMI_free_real(data) doesn't free
anything, at least not data ]
> also, vbeSetMode(init_mode,NULL) may cause trouble, since:
>
> static unsigned init_mode; /* mode before run of mplayer */
>
> is uninitialized.
it is initialized by config() first via vbeGetMode().
> > BTW, if you are in a hurry for 0.90, plz revert as I did myself.
>
> I want to see a better fix.
> That 2-liner has definitely some sence, but it may break other things, at
> your sys.
the only way I could imagine a seg fault in uninit() is by using a binary
with vesa on a box without vesa. But perhaps I'm missing something, it's late.
Perhaps Filip Kalinski (who made the patch) could explain where the
problem was in the first place... I browsed -users for that problem, nada.
Well, do as you wish, you're the master here.
/Fabien
More information about the MPlayer-dev-eng
mailing list