January 2023 - wine-gitlab

[PATCH 0/1] MR1962: wrc: Avoid undefined behavior in the FreeBSD case
by Gerald Pfeifer (＠gerald) 13 Jan '23

13 Jan '23

init_argv0_dir has a special case for FreeBSD where one branch led to an unitialized variable and undefined behavior. Initialize properly. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1962

2 1

[PATCH v2 0/2] MR1955: msv1_0: Avoid double free when SpAcceptLsaModeContext fails.
by Rémi Bernon (＠rbernon) 13 Jan '23

13 Jan '23

And a previously created context is passed, which may later be destroyed on its own, causing a double free. This happens when running the ntlm tests. -- v2: msv1_0: Avoid double free when SpInitLsaModeContext fails. msv1_0: Avoid double free when SpAcceptLsaModeContext fails. https://gitlab.winehq.org/wine/wine/-/merge_requests/1955

3 3

[PATCH 0/1] MR1955: msv1_0: Avoid double free when SpAcceptLsaModeContext fails.
by Rémi Bernon (＠rbernon) 13 Jan '23

13 Jan '23

And a previously created context is passed, which may later be destroyed on its own, causing a double free. This happens when running the ntlm tests. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1955

3 2

[PATCH 0/1] MR1959: dinput/tests: Remove the async cancel tests.
by Rémi Bernon (＠rbernon) 13 Jan '23

13 Jan '23

The tests are actually racy, and the async operation is cancellable in a very short period of time after its creation, but before it started executing. This will be hard to test precisely and it's not related to dinput tests in any way. Let's remove this to fix some spurious Windows failures. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54283 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1959

2 1

[PATCH 0/2] MR1940: Cryptnet ocsp caching
by Paul Gofman (＠gofman) 13 Jan '23

13 Jan '23

OCSP support was introduced in the latest development cycle. In improves revocation check performance in general, although the caching is currently performed by CRL revocation check only. Also, even that result is not used before performing OCSP check which goes first, effectively forcing OCSP check to be always performed when a certificate has OCSP info. That leads to performance regression in some cases. I believe once we validated revocation either way it is safe to assume the cached result valid until NextUpdate regardless of the method (that what the first patch does). Then, we can also cache the result of OCSP response the same way we do for CRL (second patch). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1940

4 8

[PATCH 0/4] MR1956: ole32: Fix several heap mismatches / double free.
by Rémi Bernon (＠rbernon) 13 Jan '23

13 Jan '23

These can be reproduced when running many of the tests, including but not only, the ole32 tests. I tried to keep the changes minimal to fix the failing tests, hopefully it should cover all the mismatches (though I'm a bit worried about the apparent dependency with combase, which has been changed to use msvcrt heap). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1956

3 5

[PATCH 0/1] MR1958: ntdll/tests: Mark some test results on Windows 11 as broken.
by Hans Leidekker (＠hans) 13 Jan '23

13 Jan '23

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

2 1

[PATCH 0/1] MR1927: tools/winegcc: Reduce race conditions.
by eric pouech (＠epo) 13 Jan '23

13 Jan '23

When doing a parallel build on multi-arch tree, it sometimes generates errors like: /usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find authz.dll-63db5999.spec.o: Aucun fichier ou dossier de ce type I added a couple of traces, showing that the two winegcc invocations for linking the DLL on the two arch:s are run in parallel *BUT* end up with the same output file. The one generated from tools.h / make_temp_file() called in winegcc{build_spec_obj()}. build_spec_obj() invokes 'winebuild -o XXX.spec.o' that starts (in -o option handling) by unlinking XXXX.spec.o. This opens a race condition on the output file name: 1) the XXX.spec.o is chosen by first arch in winegcc 2) XXX.spec.o is unlinked in winebuild (for first arch) 3) XXX.spec.o is chosen by second arch in winegcc 4) both winebuild invocations (first & second arch) now write to the same file In a nutshell, make_temp_file() isn't sufficient to ensure unicity of filename when such filename is erased (even briefly) in the build process. Proposed workaround: - use target name in generation of .spec.o filename to avoid collision. There's might other areas which could suffer from same kind of issue. Alternative options: - explicitly insert getpid() or target_alias in generated name in make_temp_file() - change value in make_temp_file (using time(NULL) + getpid() in parallel build can generate rather likely the same value in two consecutive processes) time(NULL) ^ getpid() might generate less collisions (even if it doesn't eradicate them). - change winebuild not to unlink output file but rather use open(O_TRUNC) (didn't look into it) Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1927

2 3

[PATCH 0/1] MR1952: rpcrt4/tests: Avoid invalid free of static string.
by Rémi Bernon (＠rbernon) 13 Jan '23

13 Jan '23

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

3 2

[PATCH v4 0/4] MR1683: loader: Support GDB hooking, and expose ld.so and PE modules in a wine-specific link map.
by Rémi Bernon (＠rbernon) 13 Jan '23

13 Jan '23

This makes it possible to debug Wine application in GDB almost like any other Unix application. Split from https://gitlab.winehq.org/wine/wine/-/merge_requests/1074. -- v4: ntdll: Maintain a PE module link map and expose it to GDB. ntdll: Pass a UNICODE_STRING to load_builtin and virtual_map_image. https://gitlab.winehq.org/wine/wine/-/merge_requests/1683

3 7

2025

2024

2023

2022

wine-gitlab January 2023