Overview
Artifact ID: | 77151d190a296d7b5a71210bb2d5010df78be90d11da979239816c71de82f087 |
---|---|
Ticket: | 1821174fffffffffffffffffffffffffffffffff
RenderBadPicture (invalid Picture parameter) |
User & Date: | chw 2018-01-17 23:03:22 |
Changes
- icomment:
To be more precise, let's take XFreeColors() used by TkpFreeColor() enclosed in Tk_(Create|Delete)ErrorHandler(). The implementation in 2001 X11R6 is int XFreeColors(dpy, cmap, pixels, npixels, planes) register Display *dpy; Colormap cmap; unsigned long *pixels; /* LISTofCARD32 */ int npixels; unsigned long planes; /* CARD32 */ { register xFreeColorsReq *req; register long nbytes; LockDisplay(dpy); GetReq(FreeColors, req); req->cmap = cmap; req->planeMask = planes; /* on the VAX, each pixel is a 32-bit (unsigned) integer */ req->length += npixels; nbytes = npixels << 2; /* watch out for macros... */ Data32 (dpy, (long *) pixels, nbytes); UnlockDisplay(dpy); SyncHandle(); return 1; } It makes and queues a protocol request, and finallydoes SyncHandle(). Normally, SyncHandle() is a noop except should we debug using XSynchronize(..., True); My (possibly wrong) analysis in this case is: Tk_(Create|Delete)ErrorHandler() is some kind of placebo except the wish is run with -sync which turns the SyncHandle() stuff on.
- login: "chw"
- mimetype: "text/plain"