After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 796450 - ladspa: gst_init() on Windows crashes
ladspa: gst_init() on Windows crashes
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.14.1
Other Windows
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-05-30 08:28 UTC by Milenko
Modified: 2018-07-22 18:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Stacktrace (3.52 KB, text/plain)
2018-07-20 15:54 UTC, Milenko
  Details
ladspa: Don't try and load every file as a plugin (1.50 KB, patch)
2018-07-21 23:57 UTC, Jan Schmidt
committed Details | Review
ladspa: Only scan LADSPA subdir APPDATA and COMMONPROGRAMFILES (2.18 KB, patch)
2018-07-22 00:35 UTC, Jan Schmidt
committed Details | Review

Description Milenko 2018-05-30 08:28:31 UTC
Calling gst_init(NULL, 0) within my application shows two 0xc000012f error dialogs on my Windows 10 64 bit machine with the error message that putty.rnd and winscp.rnd can not be executed. This happens only when the gstreamer registry has not been created and only when calling gst_init() within my application. The app seems to run fine after closing these error messages and the registry is also created. On a second run these error messages do not show up anymore. 

This did not happen with gstreamer 1.12.

It seems that the crypto library is enumerating the %APPDATA% directory and searches for files with the .rnd extension.

When the registry does not exist and i execute gst-inspect-1.0.exe on the command line these error messages do not appear.
Comment 1 Jan Schmidt 2018-06-08 14:51:37 UTC
I think this must be related to openssl in some way. Does it happen with the 1.14.0 build too?
Comment 2 Milenko 2018-07-20 08:47:25 UTC
No, it does not happen with 1.14.0.1
Comment 3 Sebastian Dröge (slomo) 2018-07-20 09:39:31 UTC
Just to be sure, you're saying it happens with 1.14.0 but not with 1.14.0.1 and not with 1.14.1? Or does it happen with 1.14.1?
Comment 4 Milenko 2018-07-20 09:53:41 UTC
I have reported this issue for the 1.14.1 version. It does not happen with 1.14.0.1 and it also does not happen with the 1.12.3 and 1.12.4 versions.
Comment 5 Sebastian Dröge (slomo) 2018-07-20 10:17:50 UTC
Ok, sorry for the confusion!
Comment 6 Milenko 2018-07-20 15:54:56 UTC
Created attachment 373111 [details]
Stacktrace
Comment 7 Milenko 2018-07-20 15:55:53 UTC
I debugged this a bit and found out that it is coming from libgstladspa.

gstladspa.c enumerates the APPDATA and COMMONPROGRAMFILES paths for all files and loads them using g_module_open. This calls LoadLibrary on Windows and Windows shows the 0xc000012f error message because putty.rnd can not be loaded.

I have attached a stack trace to the previous comment
Comment 8 Jan Schmidt 2018-07-21 23:41:18 UTC
Thanks for tracking down which plugin is doing that.

1.14.0 also had the ladspa plugin, so it's strange that doesn't fail too. 

Trying to g_module_open() every file it finds is pretty aggressive! Some suitable file extension checks with G_MODULE_SUFFIX would seem to be sensible.
Comment 9 Jan Schmidt 2018-07-21 23:57:57 UTC
Created attachment 373112 [details] [review]
ladspa: Don't try and load every file as a plugin

When scanning paths for LADSPA plugins, don't try and load
every random file as a module, as g_module_open ends up throwing
errors on Windows.

Use a G_MODULE_SUFFIX and GST_EXTRA_MODULE_SUFFIX suffix check as
we do for GStreamer plugins.
Comment 10 Jan Schmidt 2018-07-22 00:31:40 UTC
I think the intention was to scan a LADSPA subdirectory inside APPDATA and COMMONPROGRAMFILES rather than the entire directories too.
Comment 11 Jan Schmidt 2018-07-22 00:35:17 UTC
Created attachment 373113 [details] [review]
ladspa: Only scan LADSPA subdir APPDATA and COMMONPROGRAMFILES

Don't scan the entire APPDATA and COMMONPROGRAMFILES
path tree, just the LADSPA sub-directory inside them, if any.