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