Re: [PATCH v4 0/3] MR1003: gdiplus: Use atomic write for releasing GpImage lock.

[Esme Povirk (＠madewokherd)]

On Tue Oct 25 21:03:54 2022 +0000, Zebediah Figura wrote:
> That behaviour sounds an awful lot like gdiplus isn't thread-safe after
> all. E.g. error 7 is ERROR_ARENA_TRASHED. Should this code really have a
> lock at all?
> There are two different kinds of "locking" going on here. There's GdipLockBitmapBits, which isn't a locking mechanism at all but a way of accessing bitmap data, and the mutex we have protecting Bitmap objects.

Also, error 7 is a gdiplus Status enum value named Win32Error, not a win32 error code, so this isn't ERROR_ARENA_TRASHED.

This test case is entirely single-threaded, so it's not a race condition. The mutex-lock isn't really involved. It seems like gdiplus does not account for GdipImageRotateFlip being called while a bitmap is bits-locked. I would guess that RotateFlip changes the location of the image data, invalidating the state that UnlockBits needs to function correctly. What "should" happen in this situation is probably that GdipImageRotateFlip fails with WrongState, but it seems Windows doesn't do that.

The patches here bring us closer to the (broken) Windows behavior, although I'm really not sure how Wine will end up handling this situation in practice.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/1003#note_12125