GNOME Bugzilla – Bug 763962
GES_INIT failed and crashes on windows 10 laptop
Last modified: 2016-04-13 16:18:07 UTC
Created attachment 324398 [details] DXDiag Laptop When we init our engine we also load the dll's for gstreamer, which all load just find... afterwards we call get_init(NULL, NULL) which succeeds. Immediately after we call get_init(). For all our development machines it works just fine but for a specific laptop that we use the ges_init crashes the application we have. the point we are crashing on is ges_init() -> somewhere in gobject-2.0.0 i did downgrade to 1.6.3 and the issue is still on that device. Attached is the dxdiag for the specs of the machine ges crashes on.
Thanks for taking the time to report this. This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read https://bugzilla.gnome.org/page.cgi?id=bug-writing.html and add a description of how to reproduce this bug. You'll also need to add a stack trace; please see https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces for more information about how to do so. When providing a better description and pasting a stack trace, please reset the status of this bug report from NEEDINFO to its previous status. Thanks in advance!
Thank you Sebastian, I will try to get the stack trace for today. But the steps to reproduce are simple, 1) load gstreamer dlls Libgobject-2.0-0.dll Libglib-2.0-0.dll Libgstapp-1.0-0.dll Libgstreamer-1.0-0.dll Libffi-6.dll Libgcc_s_sjlj-1.dll Libintl-8.dll 2 ) call gst_init(null, null) 3 ) call ges_init() immediately afterward Application will crash within step 3 ... I realize this might be an edge case for the laptop we are using so I will try to get the stack trace as soon as possible
Hi Sebastion, So I built the GStreamer-Editing-Services with debug enabled and I do not seem to get the crash, it seems to only be in release of 1.7.90
Created attachment 325040 [details] Crash dump
After running ges on the laptop again we still get the same initialization crash, unfortunately because we build with vs, we don't get any debug symbols. the attached image is our call stack. I apologize for the lack of debug info on our end.
Trying running it in gdb instead of the VS debugger, that should get you a stack trace of the gcc built parts.
Hi Olivier, Before I tried running i checked the lib files that i created with cerbero, using nm -a and all my libs just return .0 files and no actual symbol data, when building with cerbero i just build the recipe, is there a different way i should be building these packages, or is there way i can get debug versions of the gst-editing-services build. Parker
Just run the application in gdb, you will get proper backtraces for all the GStreamer related code.
Backtrace from IRC (symbol names are confused by files and line numbers make sense): (gdb) backtrace
+ Trace 236177
This looks similar to bug #758738 which is related to passing a GType through a vararg function, as done in ges_asset_request(): asset = g_initable_new (asset_type, NULL, NULL, "id", real_id, "extractable-type", extractable_type, NULL);
Thanks for taking the time to report this. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 758738 ***