Race condition in XDamage

[Owen Taylor]

On Thu, 2005-02-03 at 14:57 -0500, Jonathan Lennox wrote:
> In some of my experimentation with the damage extension, I've discovered
> what appears to be a race condition in the extension definition.
> 
> If a damage report level other than DamageReportRawRectangles is chosen,
> it's possible for a client which is monitoring the contents of a window to
> miss a change to the window.  Here's the flow of events.
> 
> ("Client" is drawing to a window; "Monitor" is receiving DamageNotify events
> with level == DamageReportDeltaRectangles and using XGetImage to update its
> private pixmap of the window.)
> 
> * Monitor's damage region is empty.
> * Client draws to a region R of the window.
> * The server sends DamageNotify events to Monitor reporting damages to
>   region R.  Monitor's damage region now == R.
> * Monitor calls XGetImage on region R.
> * Client draws again within region R.  Since the drawing is contained within
>   Monitor's existing damage region, no DamageNotify events are sent.
> * Monitor calls DamageSubtract on R.
> 
> Monitor's copy of the window is now missing Client's second update!  I've
> actually observed this happening.
> 
> The potential solutions, as far as I can tell, are either to a) always use
> raw reports, or b) for Monitor to grab the server before XGetImage and
> release it after DamageSubtract.  Is there some other alternative I'm
> missing? 

Why not just reverse the calls to DamageSubtract and XGetImage? That's
the normal thing to do. You might do a little extra work if someone
draws again in-between but that's harmless.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20050203/27af502b/attachment.pgp>