While running Quickbooks Pro 99, WINE would crash every time I changed an existing transaction and clicked "Next" or "Prev", then answered Yes to save changes. It gave the following error:

X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 59 (X_SetClipRectangles) Serial number of failed request: 83724 [<--- that number changed every time] Current serial number in output stream: 87435 [<--- that number changed every time, too]

(it also still gives quite a few of these errors elsewhere in the app, but I don't know if it's related): err:x11drv:X11DRV_CreateWindow invalid window height -2

The line it was crashing on was in x11drv/clipping.c:

XSetClipRectangles( gdi_display, physDev->gc, physDev->org.x, physDev->org.y, (XRectangle *)data->Buffer, data->rdh.nCount, YXBanded );

After digging around a little, I found this Xlib programming manual entry: http://tronche.com/gui/x/xlib/GC/convenience-functions/XSetClipRectangles.ht...

Here's what it has to say on the last argument about clipping rectangle sorting:

"If known by the client, ordering relations on the rectangles can be specified with the ordering argument. This may provide faster operation by the server. If an incorrect ordering is specified, the X server may generate a BadMatch error, but it is not required to do so. If no error is generated, the graphics results are undefined. Unsorted means the rectangles are in arbitrary order. YSorted means that the rectangles are nondecreasing in their Y origin. YXSorted additionally constrains YSorted order in that all rectangles with an equal Y origin are nondecreasing in their X origin. YXBanded additionally constrains YXSorted by requiring that, for every possible Y scanline, all rectangles that include that scanline have an identical Y origins and Y extents."

Changing that last parameter from YXBanded to Unsorted has completely resolved my problem, and it doesn't seem to have broken anything else that I've noticed (Firefox, Mozilla-suite, winefile all seem to run just as well as before). However, I'm sure you all know more than I do about how that particular function works. The code for that function hasn't changed at least since the 20031212 CVS. Either way, I'm submitting a small one-line patch. Please let me know if you think this will cause issues elsewhere. Thanks!