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

[Nicolas Dufresne]

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