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

[Andreas Rheinhardt]

Soft Works:
> 
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
>> Martin Storsjö
>> Sent: Wednesday, April 20, 2022 2:48 PM
>> To: ffmpeg-devel at ffmpeg.org
>> Subject: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object sharing
>> issue on Windows
>>
>> Hi,
>>
>> I just became aware of the av_fopen_utf8 function - which was
>> introduced
>> to fix path name translations on Windows - actually has a notable
>> design
>> flaw.
> 
> Hi Martin,
> 
> I just became aware that somebody would be compiling ffmpeg like 
> this on Windows and I'm curious regarding the whereabouts..
> 
>> Background:
>>
>> On Windows, a process can contain more than one C runtime (CRT); the
>> system comes with two shared ones (UCRT and msvcrt.dll) and in MSVC
>> builds, each DLL/EXE can have one statically linked in instead of
>> linking
>> against a shared library CRT (and that's actually the default
>> configuration when building with MSVC).
> 
> The default configuration for both, EXE and DLL projects is to link
> to the C runtime dynamically (crt dll).
> 
>> This means that CRT objects (file descriptors from open(), FILE*
>> opened
>> with fopen/fdopen) mustn't be shared across DLLs; such an object must
>> be
>> opened, accessed and closed within the same DLL.
> 
> This only happens when you explicitly modify the build configuration
> to statically link to the CRT. 
> It is generally discouraged to mix (or have multiple) CRTs in a single
> process, but it's surely valid and there can be very good reasons to
> do so. Yet, such reasons are typically about achieving a certain level
> of independence between libraries and their dependencies and 
> interdependencies.
> What's probably a bit more unusual is to build libraries like the
> ffmpeg libs which are very closely related and dependent in a way
> that each of them has its own static copy of the CRT compiled into it.
> 
> I'm curious about two things:
> 
> Why are you compiling it this way?
> Your earlier patch is from 2013, so you seem to be doing so for
> quite a while.
> 
> 
> Is the file API the only case where you had any trouble?
> 
> 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.)

- Andreas