ZusiDisplay sometimes loads the same font file into two different PrivateFontCollections using two threads, so there is a race condition when the file is opened without the FILE_SHARE_READ sharing mode. The second call to GdipPrivateAddFontFile() might fail if the first one hasn't closed the file handle yet.
From: Florian Will florian.will@gmail.com
ZusiDisplay sometimes loads the same font file into two different PrivateFontCollections using two threads, so there is a race condition when the file is opened without the FILE_SHARE_READ sharing mode. The second call to GdipPrivateAddFontFile() might fail if the first one hasn't closed the file handle yet. --- dlls/gdiplus/font.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/gdiplus/font.c b/dlls/gdiplus/font.c index 96d3c5630bc..bcf36a60090 100644 --- a/dlls/gdiplus/font.c +++ b/dlls/gdiplus/font.c @@ -1110,7 +1110,7 @@ GpStatus WINGDIPAPI GdipPrivateAddFontFile(GpFontCollection *collection, GDIPCON
if (!collection || !name) return InvalidParameter;
- file = CreateFileW(name, GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL); + file = CreateFileW(name, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); if (file == INVALID_HANDLE_VALUE) return InvalidParameter;
if (!GetFileSizeEx(file, &size) || size.u.HighPart)
Hm, gitlab says the source branch must be rebased onto the target branch. But it looks like they're the same, other than my new commit added on top of the current 9e5d54ea master HEAD. Not sure what I did wrong there or what I need to do to resolve that message (I'm still using the old git://source.winehq.org/git/wine.git repo for pulls, maybe that's an issue for some reason).
Should we add a test for this? It looks simple enough.
On Tue Feb 28 19:18:32 2023 +0000, Zebediah Figura wrote:
Should we add a test for this? It looks simple enough.
I can give that a try, yes. (First open the file in the test code, then call the font loading function on the same file.)