Fw: Re: [AD] further in the bug... need help !

[Bob <ohannessian@xxxxxxxxxx>]

Emmanuel Anne wrote:
> 
> On Tue, 09 Jan 2001, Bob wrote:
> 
> >
> >
> > Emmanuel Anne wrote:
> > >
> > > I finally reproduced my old bug (sigsegv in blit when in 16bpp and
> > > converting a 8bpp bitmap to 16bpp).
> >
> > Ok, let's very this. What happens if you add the line: cpu_mmx = FALSE;
> > before you use any blit()s ?
> 
> Exactly the same : I still get :
> 
> Program received signal SIGSEGV, Segmentation fault.
> _xwin_write_line (bmp=0x0, line=1572601899) at ./src/x/xwin.c:2548
> 2548       int new_line = line + bmp->y_ofs;
> (gdb) bt
> ##0  _xwin_write_line (bmp=0x0, line=1572601899) at ./src/x/xwin.c:2548
> #1  0x804c9cd in clearMMX_loop ()

That shoudl NOT happen! If cpu_mmx is false, then the whole MMX code is
to be skipped!
Here's the code snip from iblit16.s:
   movl GLOBL(cpu_mmx), %eax     /* if MMX is enabled (or not disabled
:) */
   orl %eax, %eax
   jz clear_no_mmx


> #2  0x40094ed3 in _xwin_clear_to_color (dst=0x80685d8, color=0)
>     at ./src/x/xvtable.c:251
> #3  0x40059a85 in clear () from /usr/local/lib/liballeg-3.9.34.so
> #4  0x7030100 in ?? ()
> 
> > Assuming that is doesn't crash, then can you tell me what is the bitmap
> > size that gets passed to clear()?
> > Somehow, clearmmx sets the bitmap address to 0x0. Unfortunately,
> > clearmmx does't touch the bitmap pointer! I'll double check the code
> > anyhow, but I need you to confirm that it's really the MMX code that's
> > broken and not the non-MMX one.
> > Thanks.
> 
> 1) The line is bad in the bt only after all the bitmap has been drawn.
> This line number arrives after the last one.

So somehow, clear and clear MMX clear one more line than they should? or
am I missing something here?

> 2) A temporary fix for me at the moment is to use the debug library !
> I suppose mmx is not enabled in this library... It triggers no warning
> then.

That's not right, MMX *is* enabled in the debug lib!