Possible heap corruption (or something wrong) related to Visual Studio Debugging Environment

[David Ing]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190301/a02754cf/attachment.html>