GCC12.2 warns about dereferencing a pointer to RpcPktHdr
while it has been allocated to the size of one of the packet
(hence smaller in some cases).
/home/eric/work/wine/dlls/rpcrt4/rpc_message.c:111:26: warning: array subscript 'RpcPktHdr[0]' is partly outside array bounds of 'unsigned char[24]' [-Warray-bounds]
111 | Header->common.rpc_ver = RPC_VER_MAJOR;
This patch fixes the warnings by accessing the created object
through a pointer to their type (and not through the union).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
An array of pointers isn't conformant on 64-bit and will overrun the
destination buffer when unmarshalling. Since the purpose of this
function is to test a conformant FC_BOGUS_STRUCT, use one that is
conformant on both 32-bit and 64-bit.
The revised test coincidentally reveals that there is a problem with the
padding or alignment after a marshalled 16-bit enum, which will need to
be addressed separately.
Co-authored-by: Zebediah Figura <z.figura12@gmail.com>
In cases where this could have been use-after-free, exceptions were
caught/hidden by RpcTryFinally, but still lead to leaks since
NdrProxyFreeBuffer wasn't able to call IRPCChannelBuffer::FreeBuffer.
StdProxy_GetChannel() now AddRef() on its return value (used to set
__proxy_frame::_StubMsg::pRpcChannelBuffer), and NdrProxyFreeBuffer()
calls the corresponding Release() and clears the now-weak pointer.
This makes the behavior of these function match the observed test
results, and fixes the crash/leak when a proxy is released mid-Invoke.
It's possible for a proxy to be released during the middle of an Invoke.
E.g. a specific case where this happened was a single-shot event sink
which, upon receiving the event it was waiting for, would immediately
call DispEventUnadvise. This removed the proxy pointing to that sink
from the connection point's list of subscribers and released the last
refcount on the proxy itself.
Therefore, all state used to complete an RPC call must be on the stack;
once NdrProxySendReceive pumps STA messages and permits reentrancy,
the proxy cannot be accessed or relied on to own anything.
Add test showing MIDL_STUB_MESSAGE::pRpcChannelBuffer owns a refcount
(to ensure it can read [out] parameters from the channel)
Fix a bunch of warnings generated by this patch and the migration of
GUID.Data1 to long in ae2693e2c4
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
