https://store.steampowered.com/app/638930/Dal_Segno/ occasionally calls IDirectSoundBuffer::Lock() with writecursor == buflen and writebytes == 0.
This is illegal, so Lock() returns DSERR_INVALIDPARAM - but the game doesn't notice, and does a memcpy to fill the returned buffer.
On native, the out params are zeroed on failure, so the memcpy ends up doing the right thing.
On Wine, the out params are left unchanged on failure, resulting in memcpy(STACK GARBAGE, src, STACK GARBAGE); after a few minutes of gameplay or idling (when the size isn't coincidentally zero), it crashes.
```
6518.932:0130:01b8:trace:dsound:IDirectSoundBufferImpl_GetCurrentPosition (01FF9BC0,090BEE94,00000000)
6518.932:0130:01b8:trace:dsound:IDirectSoundBufferImpl_GetCurrentPosition playpos = 20674080, writepos = -1, buflen=20709376 (01FF9BC0, time=6518932)
6518.932:0130:01b8:trace:dsound:IDirectSoundBufferImpl_Lock (01FF9BC0,20709376,0,090BEEA0,090BEE90,090BEE9C,090BEE98,0x00000000) at 6518932
6518.932:0130:01b8:warn:dsound:IDirectSoundBufferImpl_Lock Invalid parameter, writecursor: 20709376 >= buflen: 20709376
6518.932:0130:01b8:trace:seh:dispatch_exception code=c0000005 flags=0 addr=00444C5C ip=00444c5c
6518.932:0130:01b8:trace:seh:dispatch_exception info[0]=00000001
6518.932:0130:01b8:trace:seh:dispatch_exception info[1]=0042d0b5
6518.932:0130:01b8:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised
6518.932:0130:01b8:trace:seh:dispatch_exception eax=0000008e ebx=7aa539c0 ecx=00000008 edx=00000000 esi=004dcf10 edi=0042d0b5
6518.932:0130:01b8:trace:seh:dispatch_exception ebp=090bee68 esp=090bee60 cs=0023 ss=002b ds=002b es=002b fs=0063 gs=006b flags=00010246
```
(The game is poorly written in several other ways - the segfault is caught in a SEH handler that also segfaults, repeat until stack overflow; it repeatedly unlocks critical section 004A4A28, which nothing ever locks; there's a homemade spinlock implementation at 0042CAB2; probably some more weirdness I didn't discover. But those have little or no user-visible impact, they just look ugly in the PROTON_LOG and/or game disassembly. Let's ignore them.)
...is there such a thing as too many tests? Nobody's gonna try most of what these tests do.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8632
We need to memmove 11 bytes, otherwise `buffer[10]` ends up as a copy of
`buffer[9]` which resulted in the second byte of button state being
wrongly re-used as a third byte as well.
The original code did not suffer from this - while the length check was
also one off, and likely informed the one off memmove, the buffer
pointer was just incremented so everything "moved" correctly.
Fixes: c708295ed6de ("winebus: Move Sony controllers report fixups to PE side.")<br/>
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56883<br/>
Signed-off-by: Arkadiusz Hiler \<ahiler(a)codeweavers.com\></br>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8680
--
v45: wintypes: Add stubs for IIterable<IKeyValuePair<HSTRING, IInspectable *>> to PropertySet.
wintypes: Add stubs for IMap<HSTRING, IInspectable *> to PropertySet.
wintypes: Add stubs for IObservableMap<HSTRING, IInspectable *> to PropertySet.
wintypes: Add stubs for Windows.Foundation.Collections.PropertySet.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6766