Random access violation (seg. fault) when calling GStreamer functions from MATLAB context in Windows
mgelinas at kinova.ca
Thu Mar 14 13:22:10 UTC 2019
Thank you Nirbheek and Nicolas,
The unloading of our DLL (according to comments found in the code provided
by MATLAB) is done when the user calls the command 'imaqreset' in the
MATLAB Command Window. As such, the user can use that command anytime, for
a number of reasons (for instance, after registering another IMAQ adaptor).
The good news is that somehow GStreamer remains initialized, so during the
next loading/initialization of our DDL the call to gst_is_initialized()
returns true and as a result we don't call gst_init_check() again.
Originally, I thought the issue came after the MATLAB command 'imaqreset'
(thus after the unloading our DLL), but it turns out that even if I don't
do the 'imaqreset' command, I still get the issue after around 15 seconds.
Thankfully, I have identified the source of that issue. In our DLL, we
added a custom log function for GStreamer as indicated previously
(ref. gst_debug_add_log_function(VisionAdaptor::printGstLog, NULL, NULL);).
The issue seems to occur when that function is called.
Here's the scenario observed:
- Try to stream a video feed but use the wrong IP address for the rtpsrc
- We first detect a timeout in the pipeline state change
- Then, after around 15 seconds, our custom log function gets called and
display the error messages
- Try again to stream a video feed but use the wrong IP address for the
- We detect a timeout in the pipeline state change
- Then, after around 15 seconds, MATLAB crashes with an access
as indicated previously)
However, if I don't use a custom log function, I don't get any access
Note that I have observed a similar behavior with our Linux library, which
uses GStreamer v1.8.3 on Ubuntu.
So for now, our fix is to not use a custom log function.
As a final comment, I am very (very) pleased with the MSVC-built libraries.
Thanks to that, our DLL now works perfectly within MATLAB.
Thank you again for all your help.
---------- Forwarded message ----------
> From: Nicolas Dufresne <nicolas at ndufresne.ca>
> To: Discussion of the development of and with GStreamer <
> gstreamer-devel at lists.freedesktop.org>
> Date: Wed, 13 Mar 2019 12:02:50 -0400
> Subject: Re: Random access violation (seg. fault) when calling GStreamer
> functions from MATLAB context in Windows
> Le mercredi 13 mars 2019 à 12:22 +0530, Nirbheek Chauhan a écrit :
> > On Wed, Mar 13, 2019 at 2:56 AM Marc Gelinas <mgelinas at kinova.ca> wrote:
> > > After confirming that I was able to stream my video feed with
> gst-launch (using the same pipeline), the issue was "fixed" when I tried
> again to stream from my DLL. The issue never came back.
> > >
> > This was probably because of the gst registry being out of date, you
> > must've done something that triggered an update.
> > > Unfortunately, I still have the following issue:
> > >
> > > ISSUE: A few seconds after MATLAB unloads my DLL, sometimes it crashes
> with the following backtrace:
> > > Stack Trace (from fault):
> > > [ 0] 0x00000000d32924c0
> > > [ 1] 0x000007fec1104bf3
> > > [ 2] 0x000007fec110418d
> > > [ 3] 0x000007fec1637a88
> > > [ 4] 0x000007fec1eb3032
> > > [ 5] 0x000007fec1ec4db8
> > > [ 6] 0x000007fec1ebe50c
> > > [ 7] 0x000007fec1eb8c82
> > > [ 8] 0x000007fec1ec0af1
> > > [ 9] 0x000007fec1ecccaf
> > > [ 10] 0x000007fec115320c
> > > [ 11] 0x000007feb3d8b0f4
> > > [ 12] 0x000007feb3d8a3f6
> > > [ 13] 0x000007feb3db32f7
> > > [ 14] 0x000007fec9b80369 C:\Program
> Files\MATLAB\R2018b\bin\win64\ucrtbase.DLL+00131945 o__strtoui64+00000089
> > > [ 15] 0x00000000773f59cd
> C:\windows\system32\kernel32.dll+00088525 BaseThreadInitThunk+00000013
> > > [ 16] 0x000000007755383d
> C:\windows\SYSTEM32\ntdll.dll+00342077 RtlUserThreadStart+00000029
> > >
> > > The crash seems to occur only if previously I had a failed attempt to
> stream a video feed. For instance, I specify a wrong IP address for the
> rtspsrc. Then, when I make MATLAB unload my DLL, the crash occurs after a
> few seconds. Do you have any idea what could be the root cause?
> > I don't think it's safe to unload gstreamer DLLs; at least I don't
> > know of anyone who uses that. It may be possible to make that safe,
> > though. We'd be happy to accept reasonable patches for it.
> Unfortunatly, it is not. That's the reason why you cannot do gst_init()
> after gst_deinit(). In general, when GStreamer (or any GLib based)
> project is loaded in a plugin, we simply open our self module and lead
> g_module_open (NULL, 0);
> > > Also, do you know if the release of stable version 1.16 is still
> planned for this month?
> > >
> > AFAIK, yes, unless there's some major release-blocking bug. The MSVC
> > builds are still 'beta', so issues in that will not block/delay the
> > release unless they're easy to fix.
> > Cheers,
> > Nirbheek
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel