Today, find_proxy_manager() may return a proxy manager that is about to
be freed. This happens when the proxy manager's reference count reaches
zero, but proxy_manager_destroy() has not removed the proxy manager from
the apartment proxy list.
Fix this by only incrementing the reference count if it was nonzero. If
the reference count is zero, proxy_manager_destroy() will proceed to
destroy the proxy manager after the current thread releases the
apartment lock (apt->cs).
Granted, this is fragile and far from elegant, but it seems like a safe approach for the time being. Also, the critical section and "safe" refcount increment will prevent the following race condition scenario:
> 1. Thread X: A proxy manager's refcount reaches 0 and is about to be released.
> 2. Thread Y tries to grab it, calls AddRef, notices it returns 1, and drops it.
> 3. Thread Z tries to grab it, calls AddRef, notices it returns 2, and returns it.
> 4. Thread X then proceeds to remove it from the list and free the object.
--
v4: combase: Prevent use-after-free due to a race with proxy_manager_destroy.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2752
The aim of this serie is to (re)implement dbghelp.EnumerateLoadedModules
in order to return correct 32bit & 64bit modules information for a 32bit
debuggee from a 64bit debugger.
- In this case, Wine ntdll (incorrectly) stores the paths in LdrData
(for system modules) within the syswow64 directory while native stores
them within the system32 directory
(except for 32bit ntdll which Wine correctly stores within system32).
- So now dbghelp implements the system32 => syswow64 path rewrite (for
the relevant cases), which is currently used only for ntdll.
- This allows:
- to be transparent in dbghelp if ntdll is fixed to store the same
path as native
- the paths returned by dbghelp are consistent with native (in the
64bit debugger / 32bit debuggee case mentionned above)
It must be noted that the remaining todo:s in tests are only for
the case of a 32bit debugger / 32bit debuggee in (old|new) wow setup,
where the returned paths are the (untouched from ntdll) paths, hence
in syswow64 when native reports them from system32.
- this patch doesn't modify the returned path, and we haven't noticed
any issue so far
- with redirection in place, access to the image files should be
tranparent
- so we can keep it as is (not fixing ntdll).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2830