November 2023 - wine-gitlab

[PATCH 0/4] MR4312: mshtml: Return outer windows to external callers and use refs to them.
by Gabriel Ivăncescu (＠insn) 09 Nov '23

09 Nov '23

This fixes some inconsistency issues when it comes to inner vs outer windows. On second patch I keep ref again to outer windows from the inner windows, and there are several reasons for this: * It fixes the existing tests to match native IE. * It simplifies the code (it's always valid now, no second-guessing or what-ifs needed) and gets rid of `outer_window` in HTMLDocumentNode. * It **fixes** the `outer_window` in HTMLDocumentNode → it was basically prone to crashes in niche cases since it didn't hold a ref before. We can't couple it to the inner `window` field either, because that one gets detached, and that will fail *existing* tests. For example: `events.c:3224: Test failed: put_URL failed: 80004005`. * Instead of having to keep outer window refs in specific objects, it's simpler to have it consistent everywhere. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4312

4 10

[PATCH v11 0/11] MR1074: Draft: ntdll: Improve Valgrind and GDB integration.
by Rémi Bernon (＠rbernon) 09 Nov '23

09 Nov '23

Valgrind support requires a fork, which I've published to https://gitlab.winehq.org/rbernon/valgrind. The fork implements loading DWARF debug info from PE files, instead of the old and broken upstream PDB support. I've tried to upstream these changes a long time ago but didn't receive any feedback. I think we could maybe consider keeping a fork, which I'm happy to maintain, as the changes aren't too large. We may want to investigate adding 32-on-64 support, which may require a bit more changes (to VEX specifically, because its amd64 guest doesn't support segment register manipulation). The changes here are not all related to Valgrind, and I'll create separate MR for those which may make sense independently from Valgrind / GDB. Also included is a suppression file to silent some annoying false positives, many of which are coming from the cross-stack accesses during syscalls, which are confusing Valgrind's stack heuristics. One can try this out with something like: `WINELOADERNOEXEC=1 valgrind --suppressions=tools/valgrind.supp wine64/loader/wine64 wine64/programs/winecfg/winecfg.exe` -- v11: ntdll: Avoid writing to invalid memory in i386 unix dispatcher. ntdll: Fix incorrect i386 call_user_mode_callback CFI. ntdll: Avoid marking freed block header as undefined for valgrind. ntdll: Force HEAP_TAIL_CHECKING_ENABLED flag with valgrind. ntdll: Fix valgrind notifications from ntdll.so. ntdll: Import valgrind headers for PE side ntdll. loader: Implement SystemTap RTLD probes. configure.ac: Check for systemtap sys/sdt.h header. gitlab: Install systemtap-sdt-dev packages. ntdll: Maintain a PE module link map and expose it to GDB. loader: Expose a shadow copy of ld.so link map to GDB. https://gitlab.winehq.org/wine/wine/-/merge_requests/1074

3 13

[PATCH v11 0/5] MR1088: ntdll: Avoid calling pthread_exit on thread exit.
by Rémi Bernon (＠rbernon) 09 Nov '23

09 Nov '23

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. -- v11: ntdll: Unwind i386 syscall stack frames on thread abort. ntdll: Add a syscall_cfa member to the i386 syscall frame. ntdll: Unwind x86_64 syscall stack frames on thread abort. ntdll: Add a syscall_cfa member to the x86_64 syscall frame. ntdll: Add comments to stack switches in dispatchers. https://gitlab.winehq.org/wine/wine/-/merge_requests/1088

3 7

[PATCH v6 0/11] MR441: Draft: vkd3d-shader/dxil: Implement the DXIL CMP2 instruction.
by Conor McCarthy (＠cmccarthy) 09 Nov '23

09 Nov '23

Goes atop !436. The last three commits belong to this MR. -- v6: vkd3d-shader/spirv: Introduce orderedness to comparison instructions. vkd3d-shader/dxil: Implement the DXIL CMP2 instruction. vkd3d-shader/spirv: Support bool dst register in spirv_compiler_emit_comparison_instruction(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/441

3 12

[PATCH 0/7] MR462: vkd3d-shader/ir: Keep track of hull shader phases.
by Giovanni Mascellani (＠giomasce) 09 Nov '23

09 Nov '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/462

2 7

[PATCH v5 0/11] MR441: Draft: vkd3d-shader/dxil: Implement the DXIL CMP2 instruction.
by Conor McCarthy (＠cmccarthy) 09 Nov '23

09 Nov '23

Goes atop !436. The last three commits belong to this MR. -- v5: vkd3d-shader/dxil: Implement the DXIL CMP2 instruction. vkd3d-shader/spirv: Support orderedness inversion in comparison instructions. vkd3d-shader/spirv: Support bool result in spirv_compiler_emit_comparison_instruction(). vkd3d-shader/dxil: Implement the DXIL CAST instruction. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/441

3 21

[PATCH v6 0/4] MR450: vkd3d-shader/ir: Flatten structured control flow instructions.
by Conor McCarthy (＠cmccarthy) 09 Nov '23

09 Nov '23

-- v6: vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc. vkd3d-shader/ir: Flatten structured control flow instructions. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/450

2 4

[PATCH v3 0/1] MR4002: oleaut32: Fix typelib cache race condition.
by Connor McAdams (＠cmcadams) 09 Nov '23

09 Nov '23

This fixes the following issue: - Thread X holds the typelib cache list CS, and is iterating through the list. - Thread Y calls Release on the typelib interface, reference count hits 0, it's waiting for the cache list CS to remove this typelib. - Thread X finds the typelib in the cache list, returns it, exits the CS. - Thread Y enters now the CS, removes the typelib from the cache list, and proceeds to free all of the resources associated with the typelib. - Thread X tries to use the typelib, use after free. The method used here to prevent incrementing the reference count is borrowed from MR !2752. An alternative could be to decouple the actual typelib data from the `ITypeLib2` interface itself, e.g what gets stored into the typelib cache is just the data for the typelib, which would have its own private reference count locked behind the cache list CS. When the public `ITypeLib2` interface's reference count hits 0, it'd lock the typelib cache list CS, decrement the private reference count, and if the private reference count is 0 remove it from the list. The alternative method would require major restructuring of the code, which is why I'd prefer to use the one in this MR. -- v3: oleaut32: Lock ITypeLib2 interface reference count behind the typelib cache critical section on Release. https://gitlab.winehq.org/wine/wine/-/merge_requests/4002

2 2

[PATCH v2 0/1] MR4002: oleaut32: Fix typelib cache race condition.
by Connor McAdams (＠cmcadams) 09 Nov '23

09 Nov '23

This fixes the following issue: - Thread X holds the typelib cache list CS, and is iterating through the list. - Thread Y calls Release on the typelib interface, reference count hits 0, it's waiting for the cache list CS to remove this typelib. - Thread X finds the typelib in the cache list, returns it, exits the CS. - Thread Y enters now the CS, removes the typelib from the cache list, and proceeds to free all of the resources associated with the typelib. - Thread X tries to use the typelib, use after free. The method used here to prevent incrementing the reference count is borrowed from MR !2752. An alternative could be to decouple the actual typelib data from the `ITypeLib2` interface itself, e.g what gets stored into the typelib cache is just the data for the typelib, which would have its own private reference count locked behind the cache list CS. When the public `ITypeLib2` interface's reference count hits 0, it'd lock the typelib cache list CS, decrement the private reference count, and if the private reference count is 0 remove it from the list. The alternative method would require major restructuring of the code, which is why I'd prefer to use the one in this MR. -- v2: oleaut32: Lock ITypeLib2 interface reference count behind the typelib cache critical section. https://gitlab.winehq.org/wine/wine/-/merge_requests/4002

4 8

[PATCH 0/1] MR4351: uxtheme: Remove DECLSPEC_HIDDEN usage.
by Alistair Leslie-Hughes (＠alesliehughes) 09 Nov '23

09 Nov '23

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

3 2

2025

2024

2023

2022

wine-gitlab November 2023