I have written a C++ program which is built with Visual Studio 2017. The program includes the Windows Libs for GES, Gstreamer, etc. (1.14.4) which I download from here:
https://gstreamer.freedesktop.org/data/pkg/windows/ (These libs are built with cerbero, mingw, gcc.)
My application basically builds a GES Timeline and the runs it through a pipeline.
Here is my basic question: Is there any reason to suspect that my application would not play nicely with the Visual Studio Debugger since the Gstreamer Libs are built with mingw and gcc?
Below are some more details about what I am seeing:
I see evidence of heap corruption only when I attach the Visual Studio 2017 debugger. When this debugger is attached, the program will often hang while the pipeline is running.
When I run from a GTest (just native code with VS debugger attached), the program will hang inside ntdll.dll; but it runs fine without the debugger attached.
When I run from managed code (with VS debugger attached), the program hangs inside a Thread.Sleep command (completely unrelated to the native code); but it runs fine without the debugger attached.
The behavior is always slightly different depending on subtle variations related to the debug environment. For example, I can turn on the page heap to create guards using gflags ...
gflags.exe –p /enable my_program.exe /full
... and the program might not get stuck (for some of my timelines), or it might get stuck in a different place (for some of my timelines).
When I create the guards using gflags, I do not get any explicit messages that the heap has been corrupted, but the program hangs so I'm not sure what else might be the problem.
If I use windbg the program doesn't hang.
I wonder if anybody has some intuition about what the problem is.
Locked
