[FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object sharing issue on Windows

[Martin Storsjö]

On Sat, 7 May 2022, Soft Works wrote:

>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
>> Andreas Rheinhardt
>> Sent: Saturday, May 7, 2022 6:32 AM
>> To: ffmpeg-devel at ffmpeg.org
>> Subject: Re: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object
>> sharing issue on Windows
>>
>> Soft Works:
>>>
>>>
>>>> -----Original Message-----
>>>
>>> I don't have experience with that kind of setup, but I would have
>>> thought that with separate CRTs, you could already get into trouble
>>> when you would allocate a string in the main application which
>>> you pass to any of the DLL's APIs and which might get freed by
>>> the DLL at a later time - doesn't that fail?
>>>
>>
>> Whenever any of the FFmpeg libraries takes ownership of a string or
>> another buffer*, we require it to be freeable with av_free (typically
>> by
>> saying that it needs to be allocated with the av_malloc family of
>> functions). So all allocs and frees have to happen in libavutil. This
>> is
>> also true for all the other allocations directly performed by the the
>> FFmpeg libraries.
>> (The only exceptions to this are AVBuffer(Ref)s which allow users to
>> use
>> custom allocators and destructors.)
>
> Ah yes of course, thanks for the explanation. I still wonder whether
> there aren't any other issues when multiple CRTs are being used?
>
> Or are the file IO APIs the only "weak" point with regards to
> multiple CRTs being used?

In the case of ffmpeg, yes.

For generic library design, you'd have an issue anywhere where you pass 
CRT resources around - file descriptors from open, FILE*, and indeed as 
you mentioned - allocating and freeing memory with malloc/free in 
different DLLs. But as long as the library design is such that you don't 
hand over ownership of allocations and don't pass such objects across DLL 
boundaries, there's no issue.

// Martin