|
|
Hi Nicolas,
Would it be possible for me then to build GStreamer with MSVC? Any caveats?
Any plans in the very near future for the GStreamer team to provide libraries built with MSVC?
Thank you, MarcG
---------- Forwarded message ----------
From: Nicolas Dufresne <[hidden email]>
To: Discussion of the development of and with GStreamer <[hidden email]>
Cc:
Bcc:
Date: Fri, 22 Feb 2019 10:36:15 -0500
Subject: Re: Random access violation (seg. fault) when calling GStreamer functions from MATLAB context in Windows
Le mardi 12 février 2019 à 21:42 -0500, Marc Gelinas a écrit :
> 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.
Not sure what the status, but from discussion with Nirbheek, if you mix
C++ stuff built with MSCV and MINGW you'll get this type of crash.
Maybe something to check ?
>
> 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 <[hidden email]>
> > To: Discussion of the development of and with GStreamer <[hidden email]>
> > 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, <[hidden email]> wrote:
> > > > ---------- Forwarded message ----------
> > > > From: Nicolas Dufresne <[hidden email]>
> > > > To: Discussion of the development of and with GStreamer <[hidden email]>
> > > > 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 <[hidden email]> 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
> > > > > [hidden email]
> > > > > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> > >
> > > _______________________________________________
> > > gstreamer-devel mailing list
> > > [hidden email]
> > > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
|
Locked
