nanogui: Thread: Help --- assert( "drivers/mempl4.c", line=237 )


[<<] [<] Page 1 of 1 [>] [>>]
Subject: Help --- assert( "drivers/mempl4.c", line=237 )
From: Rosimildo daSilva ####@####.####
Date: 21 Dec 1999 03:03:09 -0000
Message-Id: <199912210257.SAA08087@www1.xoommail.com>

Version: 0.87pre2

I am debuging the RTEMS porting, and get this assert()
after moving the mouse little bit. I am wondering if 
this is a bug in the Video driver or in the mouse
driver. Any points are appreciated.

Rosimildo.

--------------------------------------------------------------------
(gdb) backtrace
#0  0x116c6d in BSP_wait_polled_input ()
    at 
../../../../../../../../../rtems-19991117/c/src/lib/libbsp/i386/pc386/con
sole/inch.c:298
#1  0x110343 in __assert (file=0x12a40a "drivers/mempl4.c", line=237,
    msg=0x12a561 "w > 0") at rtems/console.c:177
#2  0x10ec82 in mempl4_to_vga_blit (dstpsd=0x14bac0, dstx=420, dsty=100,
    w=-43, h=277, srcpsd=0x1ffcd3c, srcx=357, srcy=24, op=0)
    at drivers/mempl4.c:237
#3  0x10df16 in ega_blit (dstpsd=0x14bac0, dstx=420, dsty=100, w=-43, 
h=277,
    srcpsd=0x1ffcd3c, srcx=357, srcy=24, op=0) at drivers/vgaplan4.c:211
#4  0x10b4ca in GdBlit (dstpsd=0x14bac0, dstx=63, dsty=76, width=314,
    height=301, srcpsd=0x1ffcd3c, srcx=0, srcy=0, rop=0) at devdraw.c:1458
#5  0x10216b in BitBlt (hdcDest=0x1ffcdb0, nXDest=0, nYDest=0, nWidth=314,
    nHeight=301, hdcSrc=0x1ffccfc, nXSrc=0, nYSrc=0, dwRop=13369376)
    at wingdi.c:898
#6  0x108db8 in paint3 (hDC=0x1ffcdb0) at graph3d.c:66
#7  0x106338 in WndProc (hwnd=0x1ffda54, msg=15, wp=0, lp=0)
    at demos/microwin/demo.c:237
#8  0x101073 in DispatchMessage (lpMsg=0x2b8d58) at winuser.c:27
#9  0x1064c6 in WinMain (hInstance=0x0, hPrevInstance=0x0, lpCmdLine=0x0,
    nShowCmd=5) at demos/microwin/demo.c:299
#10 0x1004e1 in rtems_main (ac=5, av=0x14c7d8) at winmain.c:49
#11 0x10e277 in POSIX_Init (argument=0x0) at rtems/rtems_init.c:80
---Type <return> to continue, or q <return> to quit---

























______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com


Subject: Re: Help --- assert( "drivers/mempl4.c", line=237 )
From: "Greg Haerr" ####@####.####
Date: 21 Dec 1999 03:35:01 -0000
Message-Id: <001501bf4b52$d45c8d60$15320cd0@gregh>

: I am debuging the RTEMS porting, and get this assert()
: after moving the mouse little bit. I am wondering if 
: this is a bug in the Video driver or in the mouse
: driver. Any points are appreciated.

Note in your stacktrace how GdBlit ends up generating a
negative width value for ega_blit.  This is the "negative
index bug" that I just fixed in pre3.  GdBlit needs to be
modified to test for negative dx and dy values.  I have
attached the source to the fixed GdBlit, or you can pull
it out of pre3.  The fix is inserting the line:
    if(dx >= 0 && dy >= 0) {...

There is a small chance that this isn't the problem, since
the negative index fix affects x and y values, not width.
You might want to test for negative width values as well,
and return from GdBlit if you get any.

Otherwise, you can turn off blitting altogether by undefining
in vgaplan4.h.

Regards,

Greg


/* Copy source rectangle of pixels to destination rectangle quickly*/
void
GdBlit(PSD dstpsd, COORD dstx, COORD dsty, COORD width, COORD height,
 PSD srcpsd, COORD srcx, COORD srcy, int rop)
{
 int DSTX, DSTY, WIDTH, HEIGHT;
 int SRCX, SRCY;

#define REGIONS 0
#if REGIONS
 RECT *  prc;
 extern CLIPREGION *clipregion;
#else
 CLIPRECT * prc;
 extern CLIPRECT cliprects[];
 extern int clipcount;
#endif
 int  count, dx, dy;

 /*FIXME: compare bpp's and convert if necessary*/
 assert(dstpsd->planes == srcpsd->planes);
 assert(dstpsd->bpp == srcpsd->bpp);
 
 /* clip blit rectangle to source screen/bitmap size*/
 /* we must do this because there isn't any source clipping setup*/
 if(srcx+width > srcpsd->xvirtres)
  width = srcpsd->xvirtres - srcx;
 if(srcy+height > srcpsd->yvirtres)
  height = srcpsd->yvirtres - srcy;

 switch(GdClipArea(dstx, dsty, dstx+width-1, dsty+height-1)) {
 case CLIP_VISIBLE:
  dstpsd->Blit(dstpsd, dstx, dsty, width, height,
   srcpsd, srcx, srcy, rop);
  GdFixCursor();
  return;

 case CLIP_INVISIBLE:
  return;
 }

 /* Partly clipped, we'll blit using destination clip
  * rectangles, and offset the blit accordingly.
  * Since the destination is already clipped, we
  * only need to clip the source here.
  */
#if REGIONS
 prc = clipregion->rects;
 count = clipregion->numRects;
#else
 prc = cliprects;
 count = clipcount;
#endif
 while(--count >= 0) {
#if REGIONS
  dx = prc->left - dstx;
  dy = prc->top - dsty;
  WIDTH = prc->right - prc->left;
  HEIGHT = prc->bottom - prc->top;
#else
  dx = prc->x - dstx;
  dy = prc->y - dsty;
  WIDTH = prc->width;
  HEIGHT = prc->height;
#endif
  /*
   * This shouldn't have to be here, but is required
   * to fix a bug where negative dx, dy values get
   * generated when UPDATEREGIONS is defined, and
   * the entire client area is obscured.  Yes, the
   * above CLIP_INVISIBLE should be returned, but
   * is not.  So we check for negative values, and
   * don't blit in that case.
   *
   * This bug only occurs when the cursor is moved
   * on non-client area during complete obscuration
   * of client area.  Normally, a WM_MOUSEMOVE
   * shouldn't be generated, which was causing
   * the app to redraw.  Perhaps the nRcUpdate 
   * member should be cleared, or the clipping
   * region completely reset...
   */
  if(dx >= 0 && dy >= 0) {
   /* calc offset into blit*/
   DSTX = dstx + dx;
   SRCX = srcx + dx;
   DSTY = dsty + dy;
   SRCY = srcy + dy;

   /* clip source rectangle*/
   if(SRCX + WIDTH > srcpsd->xvirtres)
    WIDTH = srcpsd->xvirtres - SRCX;
   if(SRCY + HEIGHT > srcpsd->yvirtres)
    HEIGHT = srcpsd->yvirtres - SRCY;

   GdCheckCursor(DSTX, DSTY, DSTX+WIDTH-1, DSTY+HEIGHT-1);
   dstpsd->Blit(dstpsd, DSTX, DSTY, WIDTH, HEIGHT,
     srcpsd, SRCX, SRCY, rop);
  }
  ++prc;
 }
 GdFixCursor();
}


[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.