There are applications that uses SRWLOCK in an invalid way and then checks its binary
representation. ~~Specifically they releases an unlocked SRWLOCK then check its bit pattern is
all-ones.~~
Tweak the representation a bit so they are happy.
--
v8: ntdll: Tweak the binary representation of SRWLOCK.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4310
There are applications that uses SRWLOCK in an invalid way and then checks its binary
representation. ~~Specifically they releases an unlocked SRWLOCK then check its bit pattern is
all-ones.~~
Tweak the representation a bit so they are happy.
--
v4: ntdll: Tweak the binary representation of SRWLOCK.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4310
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55842
The bug blames commit 059094c1c18ddc33b04eac53a72fd0eb7510be94 ("ntdll: Define heap block's BLOCK_FLAG_LFH as 0x80.") but actually before the blamed commit that worked essentially by chance.
The problem the patch is solving is that RtlValidateHeap() currently always fails for LFH blocks allocated from large block memory (vs subheap blocks). That can happen for large enough LFH block sizes. In case of the regressed game the user of RtlValidateHeap() is msvcr80.msvcrt_heap_free() which uses HeapValidate() to guess the heap used to allocate the pointer to free. I am attaching a standalone test program which can be used to reproduce the problem without the patch.
[test_lfh_validate.c](/uploads/006b04a9a00ffb7949956b66a275d5cf/test_lfh_validate.c)
--
v4: ntdll: Fix pending free block validation in heap_validate() for LFH blocks.
ntdll: Handle LFH blocks allocated in large blocks in heap_validate_ptr().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4232
There are applications that uses SRWLOCK in an invalid way and then checks its binary
representation. ~~Specifically they releases an unlocked SRWLOCK then check its bit pattern is
all-ones.~~
Tweak the representation a bit so they are happy.
--
v3: ntdll: Tweak the binary representation of SRWLOCK.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4310
On Mon Nov 6 14:46:29 2023 +0000, Yuxuan Shui wrote:
> demonstrate the leak? or demonstrate the race condition?
> in the first case, our unit test already does. in the second case, i
> don't see how that's useful? the race condition is pretty clearly there,
> simply based on the fact that the callback might be running when you try
> to cancel it.
https://gist.github.com/yshui/2f1c5c8ce9d80e9eef1db4eab51344d0 this demonstrate the `CloseThreadpool` vs running callback race.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4243#note_51113
This is the last thing needed to support non-constant offset dereferences in SM4.
It allows to perform relative addressing on temps.
Besides this, I have additional patches for relative addressing on uniforms, and input and output semantics, but these may not be useful for now, since we copy all these variables into temps instead of using them directly.
--
v5: vkd3d-shader/tpf: Support relative addressing for indexable temps in SM4.
vkd3d-shader/tpf: Move sm4_register_from_node() up.
vkd3d-shader/tpf: Support writing relative addressing indexes.
vkd3d-shader/tpf: Write register index addressing.
vkd3d-shader/tpf: Encode dst and src registers using the same function.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/435