Error of "segmentation fault while loading plugin file"

[mwmalopo]

All,

Been a user of gst1-java-core for a while now (as well as gstreamer in C/C++), never really had any issues with its use outside of a silly mistake here or there (and once those are fixed all is well). This one has me stumped however, it's likely me doing something stupid.

I am using gstreamer 1.10.4 (yes I know older, but I have had similar issue with 1.18), Java 11, and gst1-java-core-1.4.0 (and I checked against 1.3.0 as I know there was some changes in the memory handling).

Obviously the attached code snippet is a simplified version of what I am doing, but basically recording (for some time) RTSP from sources to files (in a threaded environment as it does more than just run the pipeline, one thread per source -> file). I get a very random once in a while error (everything else is fine). At first I was certain that it was a threading issue, so took multiple attempts to ensure the threading used critical sections, down to doing everything on the "main" thread (which essentially the attached example does).

The attached is meant to run over and over (in a loop, starting the application and letting it exit on its own). After some number of runs (say 20 - 200) I will eventually get:
`ERROR: Caught a segmentation fault while loading plugin file:
(null)

Please either:

• remove it and restart.
• run with --gst-disable-segtrap --gst-disable-registry-fork and debug.`

Attached code renamed from .java to .txt: FakeVm.txt

I have looked around on forums / past discussion and seen some mention of concern with some of those plugins (but they are what I seem to need as I want to keep the output file as I have it).

I appreciate any thoughts and assistance, I have to believe I'm doing something wrong.

[mwmalopo]

After much investigation I wanted to answer this for anyone else struggling with something like this.

The program I created (not the simplified one attached here, but the one that I originally had the issue with) has many Java threads (in fact it uses a thread pool), which is not recommended by this library.

With careful use of Gst.invokeLater (on play, stop, and close) and holding of pipeline objects until finished there was still the occasional issue as described above.

Turns out if you pre-load the plugins (meaning just create an Element of each and let it be garbage collected) on the main thread (right after Gst.init() call), it does the trick. I tried this initially and it failed, importantly, YOU MUST pre-load all plugins that will be used in your pipeline, not just the ones you specify in the parseLaunch() call. For example although you may not have rtpsrc as a plugin in your pipeline, that plugin may be loaded by gstreamer.

If the plugins are loaded in the main thread all is well, if the first time a plugin is loaded into the registry is from a Java thread it can lead to a segfault. I imagine that is due to a critical section or some housekeeping that is done at lower levels, but with all the plugins loaded on the main thread first, I can create pipelines on Java thread and use the Gst.invokeLater() for commanding the pipeline successfully.

I suspected I was doing something wrong, and indeed I was, but wanted to offer this up to anyone who was trying something similar.

[neilcsmith-net]

The default executor used in Gst::invokeLater and Gst::executor is a single threaded executor based around a single Java thread like any other. The problem cannot be loading in Java threads as such, but probably thread safety issues in a GStreamer plugin or a library it's using. Depending on exactly what you're doing, it can also be a library shared between the JVM and GStreamer.

[mwmalopo]

You and I are in agreement. Regardless of where it is in the memory of the process (in C libraries / plugins or wherever) it seems to me that the initial loading of plugins into memory (whether plugins you specify or are loaded on your behalf) is an operation that needs to be carefully done (I believe best done on a main thread of execution with no chance of a race).

Thanks for responding.