This fixes the following issue:
- Thread X holds the typelib cache list CS, and is iterating through the list.
- Thread Y calls Release on the typelib interface, reference count hits 0, it's waiting for the cache list CS to remove this typelib.
- Thread X finds the typelib in the cache list, returns it, exits the CS.
- Thread Y enters now the CS, removes the typelib from the cache list, and proceeds to free all of the resources associated with the typelib.
- Thread X tries to use the typelib, use after free.
The method used here to prevent incrementing the reference count is borrowed from MR !2752.
An alternative could be to decouple the actual typelib data from the `ITypeLib2` interface itself, e.g what gets stored into the typelib cache is just the data for the typelib, which would have its own private reference count locked behind the cache list CS. When the public `ITypeLib2` interface's reference count hits 0, it'd lock the typelib cache list CS, decrement the private reference count, and if the private reference count is 0 remove it from the list.
The alternative method would require major restructuring of the code, which is why I'd prefer to use the one in this MR.
--
v3: oleaut32: Lock ITypeLib2 interface reference count behind the typelib cache critical section on Release.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4002
This fixes the following issue:
- Thread X holds the typelib cache list CS, and is iterating through the list.
- Thread Y calls Release on the typelib interface, reference count hits 0, it's waiting for the cache list CS to remove this typelib.
- Thread X finds the typelib in the cache list, returns it, exits the CS.
- Thread Y enters now the CS, removes the typelib from the cache list, and proceeds to free all of the resources associated with the typelib.
- Thread X tries to use the typelib, use after free.
The method used here to prevent incrementing the reference count is borrowed from MR !2752.
An alternative could be to decouple the actual typelib data from the `ITypeLib2` interface itself, e.g what gets stored into the typelib cache is just the data for the typelib, which would have its own private reference count locked behind the cache list CS. When the public `ITypeLib2` interface's reference count hits 0, it'd lock the typelib cache list CS, decrement the private reference count, and if the private reference count is 0 remove it from the list.
The alternative method would require major restructuring of the code, which is why I'd prefer to use the one in this MR.
--
v2: oleaut32: Lock ITypeLib2 interface reference count behind the typelib cache critical section.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4002
--
v4: dmloader: Mark cached objects as loaded.
dmsynth: Don't leak modulators.
dmsynth: Free the allocated presets manually.
dmsynth: Remove useless private data checks.
dmsynth: Create one FluidSynth sample per wave.
dmsynth: Use generators to set root key and fine tune.
dmsynth: Keep track of voice/wave mapping.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4339
In general, ucrtbase allocation are used here (and later ucrtbase.free for freeing memory). RtlCreateUnicodeStringFromAsciiz() is using RtlAllocateHeap(GetProcessHeap(),...) for allocation. Using ucrtbase.free() may results in freeing from a different heap which leaks the string as best or aborts the program when heap validation is enabled.
--
v3: winmm: Fix pszSound allocation in PlaySound_Alloc().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4233