Today, the image_unlock() helper function has a data race due to
non-atomic write to GpImage's 'busy' flag which is accessible by other
threads. Also, it lacks a release fence, which means that other threads
can observe the unlocked (busy = 0) state too early when the current
thread unlocks the image; specifically, the write to the 'busy' field of
the GpImage can be reordered before the last read/write to any other
fields of the same GpImage.
Fix this by replacing the 'busy' field of GpImage with SRWLOCK.
The 'busy' field in GpImage is used as an atomic variable. The C11
standard (§5.1.2.4, paragraph 25) states that two conflicting actions to
a memory location shall be both atomic operations, or otherwise properly
synchronized; otherwise, it constitutes a data race.
However, select_frame_wic() performs a non-atomic access to the 'busy'
field on a GpImage that is potentially accessible by other threads.
This happens when select_frame_wic() copies new_image to the old image
object. Although it does attempt to preserve the value of the 'busy'
field by setting new_image->busy = image->busy first, thereby
effectively assigning an identical value to the field, it is unclear
that this does not actually constitute a theoretical, if not practical,
data race. This also prevents replacing the busy flag with a mutex or
other synchronization primitives.
Therefore, skip the 'busy' field when copying fields from the new image
to the original image object.
GdipImageRotateFlip() calls GdipBitmapLockBits() while holding the image
lock, resulting in a recursive lock.
Since GdipImageRotateFlip() uses GdipBitmapLockBits() only to obtain
Scan0 and Stride, replace them with equivalent fields from GpBitmap
itself.
Windows versions 10v1507 and below classify a provider as an HWND
provider if it returns a value for UIA_NativeWindowHandle. By ignoring
this property, we get more consistent behavior in tests between all
Windows versions.
Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>
Instead of silently leaking no longer used chunks.
Be more robust to OOM conditions.
Introducing pool_realloc().
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
We can only get a successful status that way. This matches sock_recv().
Also combine the if (alerted) blocks. Unlike the previous commits, this cannot
be separated, as it causes warnings with some versions of gcc.
Fix a test failure when theming is off. A toolbar without TBSTYLE_FLAT will fill its checked button
background rectangle when theming is inactive, overwriting the checked pattern required for the test.
Some Windows version expect output to be aligned on 4 bytes.
Notes (from i386 and x86_64 tests):
- MSVC and Mingw/gcc don't layout the two variables (sdki, sdki_ex)
the same way.
- MSVC aligns each variable on 4-byte boundary,
- MingW/GCC stores them in a 8-byte chunk, but starting from the
end of the buffer: hence none of them is on a 4-byte boundary.
So, fixing the alignment of variables is not sufficient to
workaround the compilers' discrepancy on all source code.
I didn't find a generic way to align on 4 bytes structures of size
smaller than 4 bytes (apart from adding the DECLSPEC_ALIGN to
each of the offending structures, likely not that many though).
Ideas welcomed.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53684
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
