On Fri Oct 14 13:58:34 2022 +0000, Kevin Puetz wrote:
> Looked at it some more and since I (already) gave up on trying to fix
> the todo_wine about spurious calls to MessagePending, extracting that
> much to a helper shouldn't be so bad. It was my (abandoned) theory about
> how PeekMessage/QueueStatus should interact to suppress those unwanted
> calls that made things so tangled together - and the didn't make the
> conformance tests work any better, and it had nothing to do with the
> actual application I was working on, so it got dropped.
> The existing behavior (which this MR leaves alone) just needs an early
> exit to return RPC_E_CALL_CANCELED. So I'll extract that helper too;
> fixing IMessageFilter todo will probably have to revisit this, but we
> can just preserve the status quo (and make things more readable) for
> now. No need to borrow trouble from the future when I'm out of ideas and
> not trying to tackle that anymore.
Ok, opened !1068 to start with, with just some of the simpler changes that didn't involve the timeout/pumping behavior. This PR is now rebased on top of that, but marked draft and will can sit until we that first part landed so it gets smaller.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/969#note_10760
Salvage tests and fix a leak found in another review: see https://gitlab.winehq.org/wine/wine/-/merge_requests/897#note_9175 points 1 and 2. 3. is why !897 was reverted.
This does not contain the (incorrect) changes to VariantCopyInd, but instead fixes the leak identified in VariantClear (VT_RECORD needs to free pvRecord), and the wrong allocator being used in VariantCopy (it should have been IMalloc, rather than `HeapAlloc`, as shown by the fact IMallocSpy observes these allocations).
This also cleans up some dubious behavior by the test IRecordInfoImpl, which was modifying a VARIANT that it did not own or receive as an argument in the middle of VariantClear. This was likely undefined behavior, and in any case concealed the heap leak.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1035
BTW, if the issue is only that the CFA is supposed to stay constant within a CFI procedure, would it work if we were splitting the dispatcher with some jumps / call / fake CFI procedures, at the points where we need to change its register?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10742