How to get remote debugging work for Java on Solaris - java

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.

Related

initialising h2o in Rstudio : not recognising 64-bit java

I work on Rstudio running on a dedicated linux server. I get an error initialising h2o:
> h2o.init()
H2O is not running yet, starting it now...
<simpleError in system2(command, "-version", stdout = TRUE, stderr = TRUE): error in running command>
Error in value[[3L]](cond) :
You have a 32-bit version of Java. H2O works best with 64-bit Java.
Please download the latest Java SE JDK 8 from the following URL:
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
I checked the java config and got:
system("java -version")
openjdk version "1.8.0_77"
OpenJDK Runtime Environment (build 1.8.0_77-b03)
OpenJDK 64-Bit Server VM (build 25.77-b03, mixed mode)
Apparently I have the good version of java. I have found people with similar problems on Windows. They were able to solve the problem by finding and indicating the good java path. However in the environnement I am working in, i am not sure how to do that.
Any idea on how to solve the problem ? to bypass the error ?
Check if the JAVA_HOME environment variable is set. It may be pointing to the wrong spot, tricking H2O to find the wrong one.
You want JAVA_HOME/bin/java to be a good 64-bit java.
(The other thing you can optionally do is, when you do find a 32-bit java, uninstall it. There is no real reason to have it unintentionally anymore these days; memory sizes are much bigger than 15 years ago.)

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.

HtmlUnit is throwing Out Of Memory and maybe leaking memory

I use Selenium with HtmlUnitDriver with javascript enabled and I get Out Of Memory errors (I use Java). I just browse the same page. I am only using a single GET command. Which is the solution to overcome the situation?
I've had a similar issue. It ended up being an issue with auto-loading of frames... a feature that can't be disabled.
Take a look at this: Extremely simple code not working in HtmlUnit
It might be of help.
Update
Current version of HtmlUnit is 2.10. I started using HtmlUnit from version 2.8 and each new version ended up eating more memory. I got to a point in which fetching 5 pages with javascript enabled resulted in a process of 2GB.
There are many ways to improve this situation from a javascript point of view. However, when you can't modify the javascript (eg: if you are crawling a site) your hands are tied. Disabling javascript is, of course, the best way to go. However, this might result in fetched pages being different from the expected ones.
I did manage to overcome this situation, though. After many tests, I noticed that it might not be an issue with HtmlUnit (which I thought was the guilty one from the beginning). It seemed to be the JVM. Changing from Sun's JVM to OpenJDK did the trick and now the process instead of eating 2GB of memory only requires 200MB. I'm adding version information.
Sun's (Oracle) 32-bit JVM:
$java -version
java version "1.6.0.26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)
OpenJDK 32-bit JVM:
$java -version
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.13) (6b18-1.8.13-0+squeeze2)
OpenJDK Server VM (build 14.0-b16, mixed mode)
Operative system:
$ uname -a
Linux vostro1015 2.6.32-5-686-bigmem #1 SMP Sun May 6 04:39:05 UTC 2012 i686 GNU/Linux
Please, share your experience with this.
Give more memory to the JVM by adding this to the java command line that starts the JVM in which Selenium is running:
-Xmx512m
This example give a maximum of 512 Mb to the JVM.
It depends on where you're running Selenium from. If maven, you can add it to the MAVEN_OPTS environment variable, if Eclipse, you'll need to edit the run configuration for the test class, etc.
Related to HtmlUnit:
Do not forget to call webClient.closeAllWindows();. I always put it in a finally-block around the area I use the webclient. This way it is sure that all javascript is stopped and all resources are released.
Aslo useful is setting for the webClient:
webClient.setJavaScriptTimeout(JAVASCRIPT_TIMOUT);
webClient.setTimeout(WEB_TIMEOUT);
webClient.setCssEnabled(false); // for most pages you do not need css to be enabled
webClient.setThrowExceptionOnScriptError(false); // I never want Exceptions because of javascript
JAVASCRIPT_TIMOUT should be not too high long running javascript may be a reason for memory problems.
WEB_TIMEOUT think about how long you want to wait maximal.

JOGL on linux no glcontext and XInitThreads()

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

Cannot create project in Eclim

Hello good people of Stack Overflow, I have come with yet another question for your bountiful knowledge to answer. I am having a problem using eclim, a program that integrates the features of eclipse for java development into the Vim editor.
I am unable to create a project using the syntax defined on eclim.org, which is this vim command, ":ProjectCreate /path/to/dir -n java". I am typing this like this, ":ProjectCreate /home/username/Java -n java", where username is my username. The error I get is,
Java Model Exception: Java Model Status [Java does not exist]
while executing command (port: 9091): -command project_create -f "/home/username/Java" -n java
This led me to test if Java was installed on my system, using java -version. The output is,
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
OpenJDK Server VM (build 20.0-b11, mixed mode)
So I had Java installed, and I believe that is the OpenJDK version that is not used in my eclim installation. The version I specified is Java 1.6.0_24 of the sun Java JDK. That's beside the point though, as I do have Java installed.
So that's what led me to you. One last thing I would like to add though. I am using a headless server to run the eclim server in the background. This is through Xvfb, and is also detailed on eclim.org. I don't believe that is causing the problem, but I just thought it would be handy to throw in. As always, thanks for the help that will doubtless be provided.
I have done further testing and my original comment was not the correct reason. The real problem, was that I already had a directory at ~/Java. That tried to execute that directory for the project, which it could not do.

Categories