I have a Java applet which allows me to access local storage in remote server. It works fine under Windows(IE 7.0.5730.13, Java SE 1.6.0.05). According to Java Console it downloads the native library for Java Native Interface:
ClientInterface::downloadLib: downloaded C:\Documents and Settings\user\IBM\10.10.10.65\remotedrive3d.dll in 1 attempts.
Initializing RemoteDisk v2.2
..and I'm able to access local storage devices:
Under Linux using OpenJDK 1.8.0_121 and IcedTea-Web 1.6.2 it also downloads the native library:
ClientInterface::downloadLib: downloaded /root/IBM/10.10.10.65/libibmxrdisk.so.1.0.3 in 1 attempts.
However, it fails to run with an UnsatisfiedLinkError error-message:
Initializing RemoteDisk v2.2
OpenJDK 64-Bit Server VM warning: You have loaded library /root/IBM/10.10.10.65/libibmxrdisk.so.1.0.3 which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
java.lang.UnsatisfiedLinkError: VirtualDrive.PassThroughCommand.GetSupportedDevices()LVirtualDrive/SupportedDevices;
at VirtualDrive.PassThroughCommand.GetSupportedDevices(Native Method)
at com.ibm.asm.remotedisk.RemoteDisk.buildDriveList(Unknown Source)
at com.ibm.asm.remotedisk.RemoteDisk.start(Unknown Source)
at sun.applet.AppletPanel.run(AppletPanel.java:476)
at sun.applet.AppletViewerPanelAccess.run(AppletViewerPanelAccess.java:84)
at java.lang.Thread.run(Thread.java:745)
..and I'm not able to access local storage devices:
When I start the Firefox using strace -f, then I can clearly see that libibmxrdisk.so.1.0.3 file is accessed. For example:
[pid 6741] open("/root/IBM/10.10.10.65/libibmxrdisk.so.1.0.3", O_RDONLY|O_NONBLOCK) = 48
[pid 6741] read(48, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\334S\0\0004\0\0\0"..., 52) = 52
[pid 6741] close(48)
This /root/IBM/10.10.10.65/libibmxrdisk.so.1.0.3 seems to contain strings like GetSupportedDevices:
root#s:~/IBM/10.10.10.65# strings libibmxrdisk.so.1.0.3 | grep -i GetSupportedDevices
Java_VirtualDrive_PassThroughCommand_GetSupportedDevices
GetSupportedDevices
Java_VirtualDrive_PassThroughCommand_GetSupportedDevices
root#s:~/IBM/10.10.10.65#
Is the proprietary native library libibmxrdisk.so.1.0.3 for Linux operating system probably broken? Is it possible that it is not compatible with OpenJDK? How to debug this further?
This is issue for http://icedtea.classpath.org/bugzilla/enter_bug.cgi?product=IcedTea-Web not stack overflow. As ITW developer, I will need to help with debugging a bit.
From the trace is clear architecture mishmash. I would bet your windows are 32b, but linux is (for sure) 64b machine. For some reason, ITW is downloading 32b version of your RemoteDrive library. 32b library should work on 64b system, but you need also 32b depndencies (and most likely also 32b java). Do you have them all?
If above is completly true, then it is bug i ITW, or jdk itslef. But I'm betting for above.
So: try 32 jdk, try various 32b depndencies, if not working, then please submit bug to ITW
HtH
J.
Related
I'm using NVIDIA's Visual Profiler (nvvp) to profile a kernel on a Pascal GPU (as those aren't supported by Nsight Compute) - with CUDA 11.4 on a Devuan GNU/Linux 4 system.
When I run nvvp, it crashes immediately, saying:
$ nvvp
java.lang.ExceptionInInitializerError
at org.eclipse.osgi.storage.Storage.<init>(Storage.java:97)
at org.eclipse.osgi.storage.Storage.createStorage(Storage.java:84)
at org.eclipse.osgi.internal.framework.EquinoxContainer.<init>(EquinoxContainer.java:75)
at org.eclipse.osgi.launch.Equinox.<init>(Equinox.java:31)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:295)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:231)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected void java.net.URLClassLoader.addURL(java.net.URL) accessible: module java.base does not "opens java.net" to unnamed module #21bcffb5
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
at org.eclipse.osgi.storage.FrameworkExtensionInstaller.findMethod(FrameworkExtensionInstaller.java:52)
at org.eclipse.osgi.storage.FrameworkExtensionInstaller.findMethod(FrameworkExtensionInstaller.java:59)
at org.eclipse.osgi.storage.FrameworkExtensionInstaller.findAddURLMethod(FrameworkExtensionInstaller.java:43)
at org.eclipse.osgi.storage.FrameworkExtensionInstaller.<clinit>(FrameworkExtensionInstaller.java:37)
... 14 more
Why is this happening, and how can I circumvent/fix this error?
Edit: On my system, the default JAVA VM is: openjdk 17-ea 2021-09-14. If I use a different installed vm, e.g. /usr/lib/jvm/java-11-openjdk-amd64/bin/java, I get the same error. A JDK from https://jdk.java.net/archive/ for Java 16 also doesn't change things. Adding --illegal-access=permit which someone suggested to me - also didn't help.
The InaccessibleObjectException seems to be caused by using Java 17 to run Java code that is not ready for Java 17. Java 17 is more restrictive than previous Java versions, breaking backwards compatibility in this point. Also Java 16 is more restrictive than previous versions and in the Java 11 system library packages are missing that existed in Java 8.
Instead of Java 17, use Java 16 or 11 to run an application based on a recent Eclipse version (having --add-modules=ALL-SYSTEM in the .ini file) and Java 8 for applications based on older Eclipse versions.
In the .ini file next to the executable (having the same name) you can specify the Java to be used to run the Eclipse-based application. Alternatively, you can put the Java in the jre subdirectory of the installation directory.
In addition, you might ask the vendor of the application to ship the application with an embedded Java.
Update: Robert Crovella refers to the documentation, according to which the ​Visual Profiler requires Java 8.
We recently migrated from java 8 to openJdk11. Now I am trying to test my application on windows and ubuntu with using openJdk installed on both OS. I'm able to run it on ubuntu. But same is not executing in windows10 with java11.Error_Message:
java.lang.RuntimeException: No toolkit found
at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272)
at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678)
at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
at java.base/java.lang.Thread.run(Unknown Source)
It is possible that JDK, which you have installed on your Windows system, doesn't include JavaFX and you should install it externally.
Read more here:
Where can I get pre-built JavaFX libraries for OpenJDK (Windows)
or
https://stackoverflow.com/a/19529820
or
Javafx: No toolkit found exception
.
I am not sure how the differnences between Linux and Windows come into place, but in general com.sun.javafx.tk.Toolkitis not accesible anymore since Java 9. So the behaviour on Windows throwing an exception is correct, and you need to find another solution for whatever you are using theToolkit-class for.
Well, I'm having some problems restarting my Apache Server. I modified the ulimit on the server but I'm failing to restart httpd;
I'm running the server on CentOS 5.8 x64. The output from httpd -V:
Server version: Apache/2.2.3
Server built: Jan 10 2013 08:19:28
Server's Module Magic Number: 20051115:3
Server loaded: APR 1.2.7, APR-Util 1.2.7
Compiled using: APR 1.2.7, APR-Util 1.2.7
Architecture: 64-bit
The error I'm getting when running /sbin/service httpd restart(I'm not going to print the hall output):
Syntax error on line 210 of /etc/httpd/conf/httpd.conf:
Syntax error on line 6 of /etc/httpd/conf.d/php.conf:
Cannot load /etc/httpd/modules/libphp5.so into server: libidn.so.11:
wrong ELF class: ELFCLASS32
I googled this error and tried to dig for the problem. What I found is that libphp5.so is 64-bit architecture whilst libidn.so.11 is 32-bit. Normally, as I know, there shouldn't be a problem using 32-bit programs on 64-bit architecture, but in this case there's 32-bit library used in 64-bit program(****See this related question**).
I tried to install the 64-bit version of the library but what I could find, for my O.S.(centOS 5.8) is the libidn_x86_64 version, which is again on 32-bit.
Programs installed on server:
squid - Proxy
ffmpeg - for video streaming
csf-lfd -> firewall
Apache
Any help on finding the problem is appreciated!
Since the version of libidn in CentOS 5.1 is the same as in 5.9 (indeed it's the same file), it's probably a safe bet that it will install in 5.8
could find, for my O.S.(centOS 5.8) is the libidn_x86_64 version, which is again on 32-bit.
No, the name implies it's the 64 bit version - if it contains a 32 bit object file, then something has gone way wrong - further, given the wide usage of CentOS and that libidn is required for all sorts of things, I'm sure someone would have noticed by now if the rpm contained the wrong file.
You might want to spend some time thinking about how your server got into this state. It shouldn't have been possible to install/upgrade the PHP from Centos respoitories with the right dependencies in place (unless you forced it to ignore them).
I have problems with JRE on Linux Debian 5.
JRE (sun 1.6 21) crash with SIGBUS on Debian 5 (kernel 2.6.26) during TEE-CLC java application execute.
TEE-CLC-10.1.0 is a java client application for Microsoft Team Foundation Server (TFS).
Here is the java virtul mashine command line:
exec java -Xmx512M -classpath
"$CLC_CLASSPATH" "-Dcom.microsoft.tfs.jni.native.base-directory=$BASE_DIRECTORY/native"
$RANDOM_DEVICE_PROPERTY com.microsoft.tfs.client.clc.vc.Main "$#"
When I try to execute the command (get files from server): tf get -r -force {branch_name} it start getting files and then minute or two later craches with the following error message:
A fatal error has been detected by the Java Runtime Environment:
SIGBUS (0x7) at pc=0xb77d3422, pid=29386, tid=3076802752
JRE version: 6.0_21-b06
Java VM: Java HotSpot(TM) Client VM (17.0-b16 mixed mode linux-x86 )
Problematic frame:
C [+0x422] __kernel_vsyscall+0xe
An error report file with more information is saved as:
/...../..../...../hs_err_pid29386.log
Segmentation fault.
I have about 900M free memory. I have checked limits: ulimit -a .
I have three other Linux Debian 5 computers and they works fine with the same settings.
I have checked everything . I don' t know why JRE don't work properly.
Does anybody have any idea how to handle it? What is wrong with JRE or with my Debian 5?
In my experience it is rare to get a faulty program to fail with a SIGBUS: error checking by compilers makes it hard to generate an odd memory address. The few times I've seen them recently was (IIRC) because I was using an incompatible shared library or .o file.
Is the LD_LIBRARY_PATH environment variable set for the executing program? If so, it might be causing the program to use an incorrect shared library.
I realize that I am attempting to go beyond the "supported" behavior of the manf's released drivers for Perl, after all they have only released it in package with x86 .so's.
However, since I cannot use their package with x64 Perl on a RHEL 5.4 x86_64 box, and maintaining a seperate install of x86 Perl just for this one package, I have made an attempt to get this puppy working thanks to released 64-bit .so's that accompany other driver packages for Advantage.
What I have done to this point:
download beta 10 DBI drivers, in 32
download beta 10 PHP extension (it contains 32 and x86_64)
copy the required DLLs into the ads-lib location (eg /usr/local/ads/lib64)
compile the Perl DBI driver with the path to the lib64's .so's
Good compilation, good install, good use.
The problem is that I always get :
failed: [iAnywhere Solutions][Advantage SQL][ASA] Error 6060: Advantage Database Server not available on specified server. axServerConnect (SQL-HY000)(DBD: db_login/SQLConnect err=-1)
Does anyone have any ideas?
EDIT: fixed package name in post title
EDIT: Updated title.
It appears that it's not just the x64 perl, but the RHEL 5.4 underneath that may be interfering. As commented below, I managed to shoe-horn a x86 perl onto the system, and compile the DBD::Advantage 9.99, and later replacing that with 9.10, and none of these x86 would connect either. Neither library (9.99 or 9.10) in either bit-edness will connect from this x86_64 server to the windows server's UNC path.
I have successfully mounted this share without problems, but still I cannot seem to connect to the 9.1. I have tried:
\hostname\PATH
\FQDN\PATH
\IP\PATH
and all of these variations with the port (default) 6262 included.
My windows machine connects fine, with both 9.1 and 9.99 from strawberry perl.
Check the host file on the Linux server and make sure the name of the server uses the actual IP rather then the loopback address.
Also, since you updated the client, did you also install/update the 10 beta server?
Finally, what is your connection string? Have you tried adding the port to the connection string?