Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gst.init() increasing INIT_COUNT too early #140

Open
bjarven opened this issue Feb 7, 2019 · 4 comments
Open

Gst.init() increasing INIT_COUNT too early #140

bjarven opened this issue Feb 7, 2019 · 4 comments

Comments

@bjarven
Copy link

bjarven commented Feb 7, 2019

When I run Gst.init() i sometimes get an Invalid memory access Error thrown by

GST_API.gst_init_check(argv.argcRef, argv.argvRef, error)

But since INIT_COUNT is increased before that call Gst seems to be initialized when it's not.

Perhaps INIT_COUNT should be incremented last in Gst.init(). Something like;

diff --git a/src/org/freedesktop/gstreamer/Gst.java b/src/org/freedesktop/gstreamer/Gst.java
index e1284dc..db1371e 100644
--- a/src/org/freedesktop/gstreamer/Gst.java
+++ b/src/org/freedesktop/gstreamer/Gst.java
@@ -503,7 +503,7 @@ public final class Gst {
         //
         // Only do real init the first time through
         //
-        if (INIT_COUNT.getAndIncrement() > 0) {
+        if (INIT_COUNT.get() > 0) {
             if (CHECK_VERSIONS) {
                 if (requestedVersion.getMinor() > minorVersion) {
                     minorVersion = (int) requestedVersion.getMinor();
@@ -540,6 +540,8 @@ public final class Gst {
         if (CHECK_VERSIONS) {
             minorVersion = requestedVersion.getMinor();
         }
+
+        INIT_COUNT.incrementAndGet();
         
         return argv.toStringArray();
     }
@MaZderMind
Copy link
Contributor

I don't think INIT_COUNT needs to be an AtomicInteger anyway, since all accesses happen in synchronized methods. To it is totally fine to just use an integer type here and be liberal about checking and incrementing it within any of the the synchronized methods.

@neilcsmith-net
Copy link
Member

@MaZderMind true, at least for now, but it's not the total cause of this issue which is why I didn't fix it for 1.0. It's not clear whether and in what circumstances an error thrown there is usefully recoverable for a start.

@dannysmyda
Copy link

I'm also running into this issue. I'd like to use the result of Gst.isInitialized() to enable/disable gstreamer functionality in my application if start up failed. Whats the rationale for keeping this incremented in the event of a failure?

@neilcsmith-net
Copy link
Member

@dannysmyda the rationale is covered above. Do not use Gst.isInitialized() for this purpose - have a central place in your application where you enable / disable functionality based on a single call to Gst.init() and whether it errors or not. I may deprecate Gst.isInitialized() - it is certainly not useful in its current form - if anything we really need 3 states - unintialized, initialized, and error.

I'm assuming your comment doesn't mean you're also using deinit()? If so, don't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants