JOGL on linux no glcontext and XInitThreads() - java

im trying to build my JOGL project for linux here but eclipse console shows:
Info: XInitThreads() called for concurrent Thread support
and bamm the opengl context is not created...
java -version:
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

To being able to help we would need more information,
as described in our Wiki:
http://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing
After following our bugreport recommendations, we would have your test case
and the advertised log files sent by you. Either use our forum/mailinglist or bugzilla.
When done, you may be so kind and update this issue here at stackoverflow.
Note: Indeed, if your test fails with one of our test cases, it is most likely a JOGL problem. The most obvious test would be to try to run a native opengl demo ensuring its functional on your machine. However, please follow above procedure, then we maybe able to help. ~Sven

Related

Android SDK on Debian linux has blank windows

Windows show like this:
Thinking it might be OpenJDK's fault, I downloaded Java SE JDK and pointed the run script to it. This did not appear to help.
Not sure what information to provide, other than being on debian jessie, using awesomewm, and:
~$ java -version
java version "1.7.0_75"
OpenJDK Runtime Environment (IcedTea 2.5.4) (7u75-2.5.4-2)
OpenJDK 64-Bit Server VM (build 24.75-b04, mixed mode)
Leaving this up just in case someone stumbles on it. Apparently java, in many forms, has problems with a few wms. Awesomewm included. One needs to export a 'nonparenting' variable:
export _JAVA_AWT_WM_NONREPARENTING=1
Maybe someone will come along and offer a more fulfilling answer to this problem.

Install java plugin in chrome in Ubuntu 14.04

I have installed Oracle Java 7 in my /home directory by following steps given here (by just changing the path of installation). But still I cannot see the plugin listed in the chrome://plugins tab.
I also cannot see it running in JavaTester or here. I have tried enabling by following steps provided here but nothing works.
Some specifications:
Operating System: Ubuntu 14.04
output of java -version:
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
Please comment if anything more is needed for resolving the problem
Just pull it from webupd8 servers. Follow the directions at the following link.
http://www.webupd8.org/2012/01/install-oracle-java-jdk-7-in-ubuntu-via.html
Also, this belongs on a different forum. This forum is for programming questions, installing a chrome plugin isn't really what we do. Next time post to the Ubuntu stack exchange located here.

Segmentation fault in Java 3D on Raspberry Pi

I'm trying to run a program using Java 3d on a Raspberry Pi and I'm having some problems with the native libraries. I've found a version compiled for ARM on the debian website here
http://packages.debian.org/en/wheezy/armhf/libjava3d-jni/download
I've also tried the 'dfsg-9' version.
When I try and run the program the following output is printed:
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) Client VM (build 24.0-b56, mixed mode)
A fatal error has been detected by the Java Runtime Environment:
SIGILL (0x4) at pc=0xa6e5b9e2, pid=7251, tid=3057575024
JRE version: Java(TM) SE Runtime Environment (7.0_40-b43) (build 1.7.0_40-b43)
Java VM: Java HotSpot(TM) Client VM (24.0-b56 mixed mode linux-arm )
Problematic frame:
C [libj3dcore-ogl.so+0x69e2] Java_javax_media_j3d_NativePipeline_getAWT+0x11
I don't really have any experience debugging problems to do with native code and am hoping for some advice on how to proceed with ths problem.
Thanks for reading.
Raspberry PI is based on an ARMv6 architecture processor. Debian armhf requires ARMv7 (or later). Hence an illegal instruction exception is exactly what I would expect.
Debian armel distribution works on the RPI.
However, if you are adding these packages to something like a raspian installation, that is unlikely to work, and you need to get your packages from a raspian repository.
The stacktrace indicates that your program triggered a SIGILL
SIGILL The SIGILL signal is sent to a process when it attempts to
execute an illegal, malformed, unknown, or privileged instruction.
Unless you wrote native code, this error is not your fault or doing. Try upgrading to the latest JDK (Java7 update 45) to see if this fixes it.
You can also try running your Java process with the -Xint flag to prevent any code from being dynamically compiled. Though not a long term solution, it may help identify where the error is happening. In your trace, it doesn't appear to be crashing in dynamically compiled code.

How to let the HotSpot VM be in debug mode?

The reason that I need the HotSpot VM be in debug mode, is that I want some JVM options, like -XX:+PrintCFGFile, be supported.
My current JVM version is like
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.1) (suse-3.1-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
Do I have to install some tool/patch to achieve that?
Thanks!
After searching a while, the problem looks more clear now.
The reason that I can't use the option -XX:PrintCFGToFile is because the JVM I used is the product version, not debug version.
I found such a website which provides the debug version of JVM. Below is the link:
http://download.java.net/jdk6/6u25/promoted/b03/index.html
I have tested the version jdk-6u25-ea-bin-b03-windows-i586-debug-27_feb_2011.jar It works well, the option I mentioned above can be used, and an output.cfg file would be produced after execution of a Java program.
After installation, there would be such a series of folders \jdk1.6.0_25\fastdebug>. And I get the following version info:
java version "1.6.0_25-ea-fastdebug"
Java(TM) SE Runtime Environment (build 1.6.0_25-ea-fastdebug-b03)
Java HotSpot(TM) Client VM (build 20.0-b10-fastdebug, mixed mode)
From the jdb manual:
"A VM that is to be debugged with jdb must be started with the following options: -agentlib:jdwp=transport=dt_shmem,server=y,suspend=n"
This loads in-process debugging libraries and specifies the kind of connection to be made."

How to get remote debugging work for Java on Solaris

I am trying to get remote debugging working with Java on Solaris OS. Following is what I have tried-
I have a Java class called TestP which has the main method.
When I try
java -classpath . TestP
the program works fine. But when I try adding the debug parameters to the JVM-
java -Xdebug -Xrunjdwp:transport=dt_socket,address=8001,server=y,suspend=n -classpath . TestP
It fails giving this error-
UTF ERROR ["../../../src/solaris/npt/utf_md.c":49]: Failed to complete iconv_open() setup
Can anyone please help me on figuring out why this error is coming up?? The above works fine on my Linux box.
Java version on Solaris:
Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
Java HotSpot(TM) Client VM (build 14.1-b02, mixed mode)
Java version on Linux:
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.5) (fedora-20.b16.fc10-i386)
OpenJDK Server VM (build 14.0-b15, mixed mode)
Hmm... This seems to be a known Solaris (not specific to Solaris 10) issue with Java 6, not a Java issue (see this thread).
Someone has successfully applied a workaround (see this blog post) from a Sun guy, Jeff Moguillansky, but I wouldn't recommend it and rather consider searching sunsolve for a patch as indicated on Sun's forums.
Look at this one: http://sunsolve.sun.com/search/document.do?assetkey=1-1-6586755-1 (you'll need a Sun Online Account with a valid Support Contract or Software Subscription).
Using truss I found out that the process was looking for /usr/lib/iconv/geniconvtbl/binarytables/UTF-8%646.bt and 646%UTF-8.bt, so I just copied ISO8859-1%ISO646.bt to UTF-8%646.bt and ISO646%ISO8859-1.bt to 646%UTF-8.bt (yes, it is "646", not "ISO646"!)
This is of course a very ugly workaround and I have no idea if it has any negative effects on the JVM, but at least it starts the JVM without aborting. (I did this on OpenSolaris 2009.06, btw)
If Pascal Thivent is right, then you may want to try running OpenSolaris (either on a blank machine or in a vm) and see if the problem is also there. If not, then consider using that version for now if possible.

Categories