- Wine-GitLab - list.winehq.org

[PATCH 0/1] MR1308: ntdll: Fix incorrectly sized mov in user_mode_callback_return.
by Torge Matthies (＠tmatthies) Nov. 9, 2022

Nov. 9, 2022

This caused non-interactible windows in my Wine builds, where in win32u `dispatch_win_proc_params` got inlined into `call_window_proc` and this mov overwrote the lower 32 bits of `result`, causing WM_NCHITTEST messages to always return 0 or 0xffffffff00000000 (correct result was -1 in that case). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1308

3 2

[PATCH v3 0/4] MR1088: ntdll: Avoid calling pthread_exit on thread exit.
by Rémi Bernon Nov. 9, 2022

Nov. 9, 2022

Using a dedicated exit jmpbuf and removing the need for assembly routines. When Wine handles an exception in unix code, we return to user mode by jumping to the last syscall frame. This can leave some pthread cancel cleanups registered, in the pthread internal linked list, and at the same time later overwrite the stack frame they were registered for. In the same way, jumping to the exit frame on thread exit or abort, can also leave some cleanup handlers registered for invalid stack frames. Depending on the implementation, calling pthread_exit will cause all the registered pthread cleanup handlers to be called, possibly jumping back to now overwritten stack frames and causing segmentation faults. Exiting a pthread normally, by returning from its procedure, or calling exit(0) for the main thread doesn't run pthread_exit and doesn't call cleanup handlers, avoiding that situation. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213 ### Additional note: For robustness, we should probably try to execute these cleanup handlers when unwinding the stack frames, as we would otherwise leave pthread objects in a potential problematic state (like a mutex locked, etc). It is however hard to do so when the handlers are registered from some C code: pthread C implementation is done by calling some internal pthread functions to register the handlers, and they aren't registered as standard unwind handlers. Only pthread_cancel and pthread_exit can unwind and call / unregister the C handlers, but interrupting that procedure, for instance calling setjmp / longjmp from withing our own handler isn't supported. >From C++ code, pthread cleanup handlers are registered through C++ class constructors / destructors, and it would then be possible to partially unwind and call them at the same time. -- v3: ntdll: Remove unnecessary signal_start_thread register spilling. ntdll: Remove unnecessary arch specific exit frame pointer. ntdll: Avoid calling pthread_exit on thread exit. ntdll: Create a pthread for the main thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/1088

3 14

[PATCH v3 0/3] MR1302: wow64: Handle regions extending pass the address limit in NtQueryVirtualMemory.
by Tim Clem (＠tclem) Nov. 9, 2022

Nov. 9, 2022

There are regions of virtual memory that start below the WoW user address limit but end beyond it (e.g. a large empty region between the end of 32-bit allocations and 64-bit ntdll). When queried from WoW via `NtQueryVirtualMemory(MemoryBasicInformation)`, the returned struct for such a region will have `BaseAddress + RegionSize` past the highest user address (or even worse - it may overflow 32 bits). These patches make WoW `NtQueryVirtualMemory` report a truncated size for such regions, so that they appear to end exactly at the highest user address. This fixes programs that, e.g., walk their address space using iterated calls to `VirtualQuery`. Also, make `MemoryRegionInformation` queries return `STATUS_INVALID_PARAMETER` when passed an address beyond the user address limit, like `MemoryBasicInformation` already does. -- v3: wow64: Truncate too-large regions from NtQueryVirtualMemory(MemoryRegionInformation). wow64: Return error from NtQueryVirtualMemory(MemoryRegionInformation) for a too-large address. wow64: Truncate too-large regions from NtQueryVirtualMemory(MemoryBasicInformation). https://gitlab.winehq.org/wine/wine/-/merge_requests/1302

2 3

[PATCH 0/1] MR1307: wined3d: Use the chunk allocator for GL element array buffers.
by Anton Baskanov (＠baskanov) Nov. 9, 2022

Nov. 9, 2022

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1307

3 2

Re: [PATCH v9 0/6] MR42: vkd3d-shader/hlsl: Some fixes.
by Francisco Casas (＠fcasas) Nov. 9, 2022

Nov. 9, 2022

Rebasing on top of master... -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/42#note_13842

1 0

Re: [PATCH v4 0/2] MR352: cmd: Don't loop infinitely on NUL.
by eric pouech (＠epo) Nov. 9, 2022

Nov. 9, 2022

Hi @ivyl is it just a rebase or did you change other things ? (can't get a diff between the two, gitlab says more that 1000 files changed) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/352#note_13840

1 0

[PATCH v8 0/6] MR42: vkd3d-shader/hlsl: Some fixes.
by Francisco Casas (＠fcasas) Nov. 9, 2022

Nov. 9, 2022

A mix of a miscellaneous fixes: * Fixes to failed asserts I have stumbled upon when implementing other features. * Checks required for properly supporting object components. * A couple of code improvements. -- v8: vkd3d-shader/hlsl: Use reg_size as component count when allocating a single register. vkd3d-shader/hlsl: Use the base type of the array elements in write_sm1_type(). vkd3d-shader/hlsl: Validate that statics don't contain both resources and numerics. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/42

4 10

[PATCH 0/2] MR1266: d3d8, d3d9: Build without -DWINE_NO_LONG_TYPES.
by Zebediah Figura (＠zfigura) Nov. 9, 2022

Nov. 9, 2022

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1266

3 3

[PATCH 0/5] MR1131: wined3d: Dirty rect fixes.
by Zebediah Figura (＠zfigura) Nov. 9, 2022

Nov. 9, 2022

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1131

4 7

[PATCH 0/2] MR1129: wined3d: Set the window state thread description only if it's actually a new thread.
by Zebediah Figura (＠zfigura) Nov. 9, 2022

Nov. 9, 2022

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1129

4 4