On Tue Apr 22 19:17:10 2025 +0000, Kevin Puetz wrote:
Yes, but not as rebased to master (we're quite a bit behind, so I just ran things through testbot.winehq.org before submitting rather than doing a full local build of 10.6). I'll mark as draft for now and do some more testing...
Ok, my apologies that this took so long to get back to. The fix was sound, but the test was completely flawed and I'm not sure how it seemed to work the first time. The key problem is that, since the whole scenario involves a hostapartment, the class factory will be a proxy. And to keep cross-thread traffic down, proxies keep their own refcount, with the proxy owning a single refcount to the stub, which owns a single refcount to the real implementing object. So observing the refcount of the proxy could never have shown whether the actual implementation had been leaked.
So now the test instead checks the way we observed the problem in real life - we put a "real" CLSID in to testlib.dll, and notice that the existence of any external refcounts on the class factory object has caused testlib.dll's DllCanUnloadNow to return S_FALSE.
So now the compobj test I added seems OK ole32:compobj start dlls/ole32/tests/compobj.c ole32:compobj:0c0c done (0) in 2s 1498B
However, pipeline is still showing VM failure on mac
no IP address found, is your VM running
And a failure on linux-32, not in the test I changed:
ole32:clipboard:0bf8 done (0) in 0s 5076B ole32:compobj start dlls/ole32/tests/compobj.c
which is where my new test is - the failure is later
ole32:marshal start dlls/ole32/tests/marshal.c marshal.c:4214:0.026 Test failed: got 0 marshal.c:4223:0.027 Test failed: Number of locks should be 0, but actually is 2
These marshal.c failures seem to be present in other PRs too (including ones that merged last night), so I assume they are unrelated...
-
Kevin Puetz (＠puetzk)