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

[Soft Works]

> -----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-----
> >> 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.)

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?

Thanks,
softworkz