Random access violation (seg. fault) when calling GStreamer functions from MATLAB context in Windows

Marc Gelinas mgelinas at kinova.ca
Wed Feb 13 02:42:41 UTC 2019


Hi Nicolas,

Please find attached a MATLAB crash report along with the gdb output. It
includes the disassembly code of frame #0 and of a few other frames as well.

A few things worth mentioning:

1) This time the segmentation fault occurred when
the DLL called gst_plugin_load_by_name(), instead of gst_init_check(). This
might be due to the fact that the DLL was compiled from a CMake project
with the "NMake Makefiles" generator. As a result, the compiler and linker
options were different than when using Visual Studio.

2) In initializeAdaptor(), the following GStreamer functions are called:

gst_version()
gst_is_initialized()
gst_debug_set_default_threshold();
gst_debug_add_log_function();
gst_debug_remove_log_function();
gst_init_check()
gst_plugin_load_by_name() with these plugins: "rtsp", "rtp", "libav",
"videoconvert"

The segmentation fault seems to have occurred when trying to load libav.

Thank you,
MarcG

---------- Forwarded message ----------
> From: Nicolas Dufresne <nicolas at ndufresne.ca>
> To: Discussion of the development of and with GStreamer <
> gstreamer-devel at lists.freedesktop.org>
> Cc:
> Bcc:
> Date: Mon, 11 Feb 2019 20:39:05 -0500
> Subject: Re: Random access violation (seg. fault) when calling GStreamer
> functions from MATLAB context in Windows
> Le mercredi 06 février 2019 à 21:57 -0500, Marc Gelinas a écrit :
> > Hi Nicolas,
> >
> > Thank you for the quick response.
> >
> > Please find attached 4 MATLAB crash reports, along with matching gdb
> (MinGW 64-bit) outputs.
>
> Looking at the backtrace, we can see that matlab is loading GStreamer
> inside a dynamically loaded module. And the crash occurs at some random
> call to the GStreamer debug trace system. A diassembly of frame #0
> would help investigate further. Meanwhile, maybe someone with knowledge
> of the limitation around loading GStreamer in a dynamic module could
> help ?
>
> >
> > Thank you,
> > MarcG
> >
> > On Wed, 6 Feb 2019 at 02:13, <
> gstreamer-devel-request at lists.freedesktop.org> wrote:
> > > ---------- Forwarded message ----------
> > > From: Nicolas Dufresne <nicolas at ndufresne.ca>
> > > To: Discussion of the development of and with GStreamer <
> gstreamer-devel at lists.freedesktop.org>
> > > Cc:
> > > Bcc:
> > > Date: Tue, 5 Feb 2019 22:42:32 -0500
> > > Subject: Re: Random access violation (seg. fault) when calling
> GStreamer functions from MATLAB context in Windows
> > >
> > >
> > > Le mar. 5 févr. 2019 16 h 57, Marc Gelinas <mgelinas at kinova.ca> a
> écrit :
> > > > Hello,
> > > >
> > > > I wonder if anyone has ever been able to use GStreamer libraries
> with MATLAB in Windows.
> > > >
> > > > Context
> > > > -------
> > > > We are developing a custom adapter to be used with MATLAB's Image
> Acquisition Toolbox add-on library (imaqmex.mexw64). Our adapter is a
> library (.dll in Windows) and uses GStreamer to access an RTSP video feed.
> > > >
> > > > MATLAB --> imaqmex.mexw64 --> our_custom_adapter.dll --> gstreamer
> libraries
> > > >
> > > > The components are:
> > > > - Windows 7
> > > > - MATLAB R2018b (v9.5.0.944444) with Image Acquisition Toolbox v5.5
> > > > - GStreamer libraries v1.14.4 for Windows
> > > > - Visual Studio 2015 (because it appears that the imaqmex.mexw64 was
> built with VS 2015).
> > > >
> > > >
> > > > Issue
> > > > -----
> > > > At some point in MATLAB's Command Window, we type 'imaqhwinfo'. This
> results in the Image Acquisition Toolbox library calling our adapter's
> initialization code, which in turn calls gst_init_check(), after checking
> that it's not already initialized (i.e. gst_is_initialized).
> > > >
> > > > Then, somewhere along the line, an access violation (segmentation
> fault) randomly occurs in a GStreamer function (doesn't always occur when
> calling the same function). I have noticed that it often occurs when
> "calling" GST_LOG or GST_DEBUG macros, but it can also occur when calling
> any other function. For instance, calling gst_tag_register from plugin_init
> (isomp4-plugin.c).
> > > >
> > > > It looks like there's an alignment issue between the MATLAB context
> and the GStreamer libraries.
> > > >
> > > > I've tried to change multiple compiler and linker options but I
> didn't find any combination to make it work.
> > > >
> > > > - Does anyone have any idea what could be the issue and how to fix
> it?
> > >
> > > Best would be to share a backtrace of the crash, with additional
> information about local variables and their location.
> > >
> > > If it's always in a logging function, you would try and provide as
> many different logging functions that crash, from there we may find
> something they have in common.
> > >
> > > > - Is it just a question of setting the proper compiler/linker
> options or it's more complex than that?
> > >
> > > It can be from very simple to very complex. GStreamer is built with a
> very ancient Mingw toolchain, which sometimes have some oops. We are
> working on moving to something newer, but this is still being worked on.
> > >
> > > An example issue we faced, was that this old mingw was not aligning
> the stack properly for use with vector variables (from intrinsic, like SSE
> instructions). We workaround that using compiler hints, that was on 32bit
> windows only though.
> > >
> > > For log function, we use a lot of vararg, and variable size must fit
> the format. I'm also wondering if the calling convention or just the mix of
> compiler may not have some incompatibility we are not aware of.
> > >
> > > > It must be noted that with Linux, the same code (obviously with
> appropriate #ifdef/#ifndef _WIN32 where required) works without any issues.
> > > >
> > > >
> > > > Finally, in the GStreamer instructions for Installing on Windows,
> it's said that the property pages only work with Visual Studio 2010. What
> do we need to change to make them work with Visual Studio 2015? I didn't
> face any issue loading them in Visual Studio 2015.
> > >
> > > That is likely just outdated doc (and slightly miss written) I imagine
> it was meant to say that you need *at least* VS 2010. Of course it could
> break in the future, we have not control over that, but the is not report
> in the direction yet.
> > > >
> > > >
> > > > Thank you in advance for any help, it will be greatly appreciated.
> > > >
> > > > Regards,
> > > > MarcG
> > > > _______________________________________________
> > > > gstreamer-devel mailing list
> > > > gstreamer-devel at lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> > _______________________________________________
> > 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...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190212/6fda138a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: matlab_crash_dump.18152-1
Type: application/octet-stream
Size: 13324 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190212/6fda138a/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb_trace_18152.log
Type: text/x-log
Size: 611157 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190212/6fda138a/attachment-0001.bin>


More information about the gstreamer-devel mailing list