When using the com.sun.tools.attach API on my Windows machine, I get the following error when making a call to
VirtualMachine.list()
java.lang.UnsatisfiedLinkError: no attach in java.library.path
The reason is the missing attach.dll. The attach.dll is located in $JRE/bin/. When starting my Java program with -Djava.library.path=[Directory to the attach.dll] everything works out without error output.
Now, I don't want to add every Java program start this ugly JVM parameter. Therefore my questions are:
Is my machine not configured right and the $JRE/bin/ should be in the library path anyway?
If not, how can I add the path dynamically? System.setProperties("java.library.path",StringOfThePathToTheAttach.dll); does not work out. The library path is changed, but the error apperas anyway. Has this something to do with SecurityManager or JVM start up?
Just found a link that might answer your question
"The java.library.path is read only once when the JVM starts up. If you change this property using System.setProperty, it won't make any difference."
http://fahdshariff.blogspot.jp/2011/08/changing-java-library-path-at-runtime.html
Your System.setProperty("java.library.path", StringOfThePathToTheAttach.dll); should work. My guess is that you're calling it too late. In other words, there is an attempt to access the DLL prior to you setting the property.
Can you output the current value for java.library.path after the property is set in code and again before the offending method call?
i.e. If you see "Before attach.dll call" output prior to seeing "After setting property", you know where your problem is.
Edit:
A better way to point to native libraries is to use System.load(StringOfThePathToTheAttach.dll) - again, before the offending line of code.
System.setProperty("java.library.path", System.getProperty("java.library.path") + File.pathSeparator + FOLDER_THAT_CONTAINS_ATTACH_DLL);
Related
I'm trying to use to G-WAN webserver. So I added a ".jar" application to CLASSPATH in order to call it from java servlet.
The code is running, but it is unable to catch the exception, and the application crashes.
Below you can find the output:
'import site' failed; use -v for traceback
ptrace: Operation not permitted.
No frame selected.
Signal : 11:Address not mapped to object
Signal src : 1:.
errno : 0
Thread : 2
Code Pointer: 7f22eda66ac7 module:libjvm.so function:Arena::set_size_in_bytes(unsigned long) line:0
Access Address: 000000000020
Can you confirm if G-WAN Java examples were running fine in the first place (even with exception handling)?
If so, your loaded .jar is the place to start with - or maybe the way the JVM loaded it from G-WAN's servlet.
That's clearly a JVM class loader issue but investigating it would require using your exact same .jar and settings, and digging into JVM internals.
i am trying run the websphere liberty profile server from the command line. I am following the steps told here : https://developer.ibm.com/wasdev/downloads/liberty-profile-using-non-eclipse-environments/
I have created the server with the name server1.
But when the extraction completes and I try to start the server using the command : server start server1
the server throws an error : CWWKE0054E: Unable to open file C:\wlp\wlp\usr\servers\server1\logs\C:\Users\Furquan\AppData\Local\Temp\\ihp_custom_batches.log.. Now I know this cant be a valid path, but I dont know where and how to change it. Please help !!
This error is related to the LOG_FILE environment variable that you have defined in your environment by some other program. To solve that, you have the following opions:
Remove LOG_FILE env variable, if it is no longer needed by your system
If you cant do that, override it via server.env file, that you can create in the wlp\usr\servers\serverName directory with the following content:
LOG_FILE=console.log
As last resort (this is not recommended, will make your installation NOT SUPPORTED and in certain installations might get overwritten by updates) - modify the server.bat command line script - in the script find the following section:
if not defined LOG_FILE (
set X_LOG_FILE=console.log
) else (
set X_LOG_FILE=!LOG_FILE!
)
And after the line set X_LOG_FILE=!LOG_FILE! just add another line that will override it with the default like this set X_LOG_FILE=console.log
In general, I'd recommend second solution (with the server.env file), as it is the most portable and will work in any environment.
I have the similar problem for IBM Support Assistant V5. After I deleted %LOG_FILE% from Environment Variables, it worked.
On a particular server (Windows 2012 server R2) I am having trouble creating a temp file. I get the following error everytime I try.
java.io.IOException: The system cannot find the path specified
at java.io.WinNTFileSystem.createFileExclusively(Native Method)
at java.io.File.createTempFile(Unknown Source)
etc..
The error happens everytime the following code is ran:
InputStream inputStream = portalBean.createPDF( sessionID, foCode );
Things I have tried
Changed the java.io.tmpdir variable on the fly. System.setProperty("java.io.tmpdir", "C:\\");
Added -Djava.io.tmpdir=c:\\temp to the webnetwork lax file to an unrestricted location.
I tried setting the webNetwork service to run as a specified user with rights to temp files e.g. the Administrator.
Made sure I have free disk space and I cleaned out the c:\windows\temp folder.
Made sure the tmp environment variables were set to their default values.
I also tried running the service from a command prompt which was opened with the Run As Administrator option.
And the IOException lingers still. I have another server running the same code without issue (Windows Server 2012).
Does anyone else have any Ideas of what else I can try to resolve this issue? And or any tips on how I can debug the issue more thoroughly to get a grasp of what is going on?
One tool you can use to debug this is process monitor from system internal tool kit. The step is: add a filter to only monitor your process (I think it is javaw.exe in your case), after the error happens, go through the file activities in the process monitor log, you can find how the process is finding files and which directories the process searched. If the process is searching in the wrong directory, you can find it from the log.
I just used this tool to figure out a JVM crash problem today.
Based on the description of your problem, I guess the path variable of the process is changed in the middle of your code, with another tool process explore you can view the path variable of the process, it might help.
Try and create instead a directory somewhere under your home directory:
final Path tmpdir = Paths.get(System.getProperty("user.home"), "tmp");
Files.createDirectories(tmpdir);
System.setProperty("java.io.tmpdir", tmpdir.toAbsolutePath().toString());
Then try and Files.createTempFile() in there.
Note that if Files.createDirectories() refers to an existing file which is not a directory, you'll get a FileAlreadyExistsException.
Please see the passage "RMI Registry Issue" of this article for the background on Java Update 1.6.0_29 first.
If I understand correctly (I'm german), the update introduces a bug in the rmiregistry which fails to work with the file: pattern in the codebase.
I.E. the following won't work any more with 1.6.0_29:
-Djava.rmi.server.codebase="file:myproject/bin/ ..."
We are currently using the feature of having a codebase with file: syntax. Does anyone know a workaround for making this work?
Note: No, we do not want to start a local webserver or ftp server.
Update:
On Naming.bind this exception is thrown:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: access to class loader denied
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:400)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:248)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
I had the same problem, and can confirm that downgrading JDK to earlier version solves the problem. I know, it's not a solution you're looking for, but at least it makes it to work.
Take running in windows as an example:
Step 1. In C:\Users\Jimmy.java.policy (create it if not exist), append below content:
grant { permission java.security.AllPermission; };
Of course "C:\Users\Jimmy\" is the user home, please change to your home accordingly.
Adding AllPermission is just for quick resolving your issue. you'd better config a more accurate FilePermission here.
Step 2. Start rmiregistry:
C:\JDK\bin>rmiregistry -J-Djava.rmi.server.codebase=file://C:/workspaces/MyLab/target/classes/
(Please note codebase must ended with "/")
Step 3. Run your server and client program.
References:
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/codebase.html
http://docs.oracle.com/javase/7/docs/technotes/guides/security/spec/security-spec.doc3.html
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/enhancements-7.html
It looks like there is no workaround because it is a bug, so wait for the fix
See details at
https://bugzilla.redhat.com/show_bug.cgi?id=751203
Code fix
http://icedtea.classpath.org/hg/icedtea6/rev/67df573b0734
If you do not need dynamic code downloading (in which case you can use ftp codebase) the solution is simply to set CLASSPATH environment variable to the path to your jar file:
Windows:
set CLASSPATH="path_to_jarfile"
Linux (batch):
CLASSPATH="path_to_jarfile"
export CLASSPATH
Best place to do it is in some script that invokes the RMI server.
Setting class path in the command line (-cp option) when starting RMI server does not help because it does not affect rmiregistry classpath!
If you start the rmiregistry in the working directory of your project, it works.
So essentially working directory of your project and current directory for rmiregistry should be same.
I recently encountered this issue as well. I can confirm that when using the file: protocol the rmiregistry must either:
be started in the root of the directory containing the shared classes; or
set the classpath to point to the shared classes or shared class jar; or
use a protocol other than file:// (I set up ngnix and served the jar from that).
Maybe not what you want, but you could resolve this with classpath rather than codebase. The client JVM will work fine if you add the required classes to its classpath. If you are using the file: URL scheme, then the classes must already be available on the localhost.
I had the same problem but I couldn't change the JDK version. Turns out you can solve it by running/starting the rmiregistry from the same directory as your code base, which in my case was target/classes. So cd project/target/classes and then run rmiregistry &
I have a program that makes use of the following method to get a scaled instance of an image icon:
public ImageIcon createScaledImageIcon(String filename) {
ImageIcon icon = new ImageIcon(filename);
Image image = icon.getImage().getScaledInstance(cardWidth, cardHeight, Image.SCALE_SMOOTH);
icon.setImage(image);
return icon;
}
I don't know if it's the source of the problem or not. But i get the following error messages:
Exception in thread "Image Fetcher 0" java.lang.UnsatisfiedLinkError: sun.awt.image.ImageRepresentation.setBytePixels(IIII[BIILsun/awt/image/ByteComponentRaster;I)V at sun.awt.image.ImageRepresentation.setBytePixels(Native Method)
at sun.awt.image.ImageRepresenation.setPixels(Unknown Source)
at sun.awt.image.ImageDecoder.setPixels(Unknown Source)
at sun.awt.image.GIFImageDecoder.sendPixels(Unknown Source) ...
Let me know if there is any other information I could include that might be of use.
Try reinstalling the latest version of Java. Your installation may have been incomplete/corrupt (read similar experience).
A user at this link suggests that this error may be the result of receiving a Java response and not rebooting. Whether "rebooting" referes to the entire computer, or just restarting java is unknown, though.
I had this same problem with a Squirrel SQL install on a Windows machine. It turned out that the cause was the environment setting for the PATH. I had set JAVA_HOME to point to the Java version I installed, but there was another version of Java in the path earlier than the one I had installed (which was sitting at the end of the path).
So my JAVA_HOME setting was not right for the version of Java which was actually being run at the command line when you typed "java".
If you see this, you might try making sure that your JAVA_HOME environment variable points to the Java you installed and make sure that it appears first in your path.
javadoc says, Thrown if the Java Virtual Machine cannot find an appropriate native-language definition of a method declared native.
guess java does not know how to read the image u specified.. use a .gif format.