[<<] [<] 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 [>] [>>] |