__STRINGTOLD_L expects a pointer to a `_LDOUBLE` as its first argument, which we internally declare
as `MSVCRT__LDOUBLE`. Problem is, `_LDOUBLE` is 10 bytes long, whereas `MSVCRT__LDOUBLE` is 12 bytes
long (ULONG * 3). Writing into the third ULONG is technically a buffer overflow.
Declare `MSVCRT__LDOUBLE` instead as 2 ULONGs plus a USHORT.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7961
On Fri May 2 17:55:41 2025 +0000, Elizabeth Figura wrote:
> > > I guess native is supposed to not block in that case
> >
> > That's a good point. If we have two streams call
> `IMFMediaStream::RequestSample`, then we will process them in sequence
> rather than in parallel. That is, one stream will have to wait for the
> other to receive data (as we block all other streams once the source cs
> is acquired in `source_async_commands_Invoke`).
> >
> > This MR will at least unblock a stream when there is no more data, but
> Windows probably delivers data for the other stream immediately (i.e. it
> can deliver data for one stream, even if the other was already waiting).
> And I believe I recall seeing audio latency in Wine as a result of this.
> From memory, it was a 4K video, so delivery of the video sample took a
> while and as a result the audio fell behind. We should probably look to
> lock the individual streams rather than the entire source when possible.
> Hrm, I didn't think we had a locking problem, but if we do that should
> be fixed, yeah.
I'll have a think about how I can test this. I might be able to craft a file that'll delay one of the streams long enough, that whilst waiting for a sample, I can reliably request and receive a sample on the other.
Thanks for the review.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7824#note_102482