BZ #71: "Local assertion failed" when running a simple gstreamer-java application

Status fields:

I get an error when trying to launch this simple application:

import org.gstreamer.Pipeline;
import org.gstreamer.Gst;
import org.gstreamer.State;
import org.gstreamer.Element;
import org.gstreamer.ElementFactory;
public class SimplePipeline {
    public static void main(String[] args) {
        args = Gst.init("SimplePipeline", args);
        Pipeline pipe = new Pipeline("SimplePipeline");
        Element src = ElementFactory.make("fakesrc", "Source");
        Element sink = ElementFactory.make("fakesink", "Destination");
        pipe.addMany(src, sink);
        src.link(sink);
        pipe.setState(State.PLAYING);
        Gst.main();
        pipe.setState(State.NULL);
    }
}

I launch:

cacao -cp .:./gstreamer-java-0.7.jar:./jna-3.0.2.jar SimplePipeline

and I get this error:

cacao: localref.c:335: localref_add: Assertion 'lrt != ((void *)0)' failed.
Aborted (core dumped)

And I get similar errors with any type of pipelines

This seems to be a problem with the application itself, or at least the libraries it's
using.  There is a thread which calls JNI functions after it has been detached:

$ cacao -XX:+TraceJNICalls -cp gstreamer-java-0.7.jar:jna-3.0.2.jar:. SimplePipeline
<snip>
LOG: [0x0000000040884950] jni_DetachCurrentThread(vm=0x602450)
LOG: [0x0000000040884950] jni_GetEnv(vm=0x602450, env=0x40883940, version=65540)
LOG: [0x0000000040884950] jni_NewLocalRef(env=0x602130, ref=0x80f5d0)
cacao: localref.c:335: localref_add: Assertion `lrt != ((void *)0)' failed.

I'm not sure this is allowed by the spec.

The same thing happens when Eclipse (3.4.1) tries to pop up the yellow quick-help
window. Here the stack looks like this:

Thread 2 (Thread 0x7fbd79929950 (LWP 19982)):
#0  0x000000393b00ec2f in waitpid () from /lib64/libpthread.so.0
#1  0x0000003f6a46f149 in g_spawn_sync () from /lib64/libglib-2.0.so.0
#2  0x0000003f6a46f458 in g_spawn_command_line_sync () from /lib64/libglib-2.0.so.0
#3  0x00007fbd905446ae in ?? () from /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so
#4  0x00007fbd90544759 in ?? () from /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so
#5  <signal handler called>
#6  0x000000393a432f05 in raise () from /lib64/libc.so.6
#7  0x000000393a434a73 in abort () from /lib64/libc.so.6
#8  0x000000393a42bef9 in __assert_fail () from /lib64/libc.so.6
#9  0x00007fbd994c62a7 in localref_add (o=0x7fbd98643340) at localref.cpp:334
#10 0x00007fbd994bdb7e in jni_NewLocalRef (env=0x7fbd998a8ec0, ref=0x7fbd98643340) at
jni.cpp:1217
#11 0x00007fbd994bdce8 in _Jv_JNI_NewLongArray (env=0x7fbd998a8ec0, len=4) at
jni.cpp:2808
#12 0x00007fbd8accfab9 in callback ()
   from /usr/lib64/eclipse/configuration/org.eclipse.osgi/bundles/98/1/.cp/libswt-
gtk-3449.so
#13 0x00007fbd8ace15ee in fn81_4 ()
   from /usr/lib64/eclipse/configuration/org.eclipse.osgi/bundles/98/1/.cp/libswt-
gtk-3449.so
#14 0x0000003754c75f7c in ?? () from /usr/lib64/xulrunner-1.9/libxul.so
#15 0x000000375542a1a3 in ?? () from /usr/lib64/xulrunner-1.9/libxul.so
#16 0x00000037554292b9 in ?? () from /usr/lib64/xulrunner-1.9/libxul.so
#17 0x000000375542a1fd in ?? () from /usr/lib64/xulrunner-1.9/libxul.so
#18 0x000000375542a304 in ?? () from /usr/lib64/xulrunner-1.9/libxul.so
#19 0x0000003755440095 in ?? () from /usr/lib64/xulrunner-1.9/libxul.so
#20 0x000000375543e552 in ?? () from /usr/lib64/xulrunner-1.9/libxul.so
#21 0x0000003755410242 in ?? () from /usr/lib64/xulrunner-1.9/libxul.so
#22 0x000000375543ed23 in ?? () from /usr/lib64/xulrunner-1.9/libxul.so
#23 0x000000394c829b33 in ?? () from /lib64/libnspr4.so
#24 0x000000393b0073da in start_thread () from /lib64/libpthread.so.0
#25 0x000000393a4e62bd in clone () from /lib64/libc.so.6

As Christian said, this was most likely a problem with the application itself. And the
issue I reported with Eclipse is also gone with more recent versions.