2

I have learned the hard way, it's not very good to share heap pointers between two dlls who each depends on different MS VC runtime. Fair enough. Based on this experience and current weird behavior of a program chain being debugged I would like to ask a

Question:

Could lib1.dll using one runtime (eg. msvcrt.dll) possibly damage heap of lib2.dll using different runtime (eg. vcruntime140d.dll)? No pointers shared, just pairs of malloc/free on the same runtime.

Background: (for those who would ask for it)

  • I have standard zeranoe ffmpeg libraries dependent on msvcrt.dll.
  • I created small C dll covering required functionality based on those ffmpeg libs, let's call it libvideo.dll. It's dependent on VS2015 runtime.
  • I created libvideosharp.dll a managed C# wrapper library (also VS2015) for libvideo.dll (marshalling).
  • I created C# test app using the libvideosharp.dll (also VS2015).
  • Debugging the C# test app (and associated libraries in the chain) I experience following:
    1. libvideo.dll mallocs and inits a data structure.
    2. libvideo.dll calls some ffmpeg init routines (av_register_all, avformat_network_init) which might malloc on its own runtime.
    3. libvideo.dll's data structure is corrupted (not even passed to ffmpeg libs in any way, just independent malloced block).
sharpener
  • 1,383
  • 11
  • 22
  • 1
    This issue was addressed in VS2012, msvcrt120.dll and up now always use the default process heap so this problem can no longer occur. However, if you see code use the private msvcrt.dll (meant to only be used by operating system DLLs) then you certainly can have this problem back, I think MinGW is the chief evil-doer. The av_xxx functions you quote are not a strong lead, consider that libvideo might just be built with a different version of ffmpeg. These libraries were written with the assumption that the user will always build them from source, the Unix way. – Hans Passant May 25 '16 at 07:14

0 Answers0