I am trying to install IBM RAD, while installation, I am getting this error -
JVM terminated exit code=8096
And the installation stops. Is there any way to rectify this problem? Why Does JVM terminates? I verified that this is the jre from IBM which is crashing.
one thing you could try is to delete the shared classes cache because this error may be caused by a corrupted cache, the commands to do that are:
java -Xshareclasses:listAllCaches // to see the caches you have
java -Xshareclasses:destroy,name=myCacheName // to destroy the cache
Or just
java -Xshareclasses:destroy // to destroy all caches...
more information here...
The solution of this problem was to DISABLE the Device3d driver. After disabling the "DirectDraw" and Direct3D accelerations, RAD installed fine.
Way to disable is - Open Display Properties -> Settings -> Advanced->Troubleshoot
And lower the Hardware Acceleration to "Disable all but basic accelerations".
Related
I have a Java app installed with Install4j.
The app started failing with the dreaded error "The JVM could not be started. The maximum heap size (-Xmx) might be too large or an antivirus or firewall tool could block the execution"
After investigation it turned out that Java did an automatic upgrade from 8.111 to 8.131 and install4j was still going to the old version. The fix was to edit \.install4j\inst_jre.cfg and change the contents from
c:\program files (x86)\java\jre1.8.0_111
to
c:\program files (x86)\java\jre1.8.0_131
However, that is not a very user friendly thing to have to do. Is there any way to have the install use something more flexible? Like going through C:\ProgramData\Oracle\Java\javapath? Or anything else.
Thanks
I just installed Android Studio on Elementary OS 0.3 Freya and run it using the terminal. On my first start-up, however, there's an error message shown:
Gradle 'Test' project refresh failed
Unable to start the daemon process. This problem might be caused by
incorrect configuration of the daemon. For example, an unrecognized
jvm option is used. Please refer to the user guide chapter on the
daemon at http://gradle.org/docs/2.2.1/userguide/gradle_daemon.html
Please read the following process output to find out more:
Unrecognized VM option 'MaxPermSize=256m' Error: Could not create the
Java Virtual Machine. Error: A fatal exception has occurred. Program
will exit.
I read this and tried all the ways to solve it but to no avail. I did notice that his error was somewhat different from mine and thought that might be why I couldn't solve my problem using the ways suggested.
As I executed the .sh file on my terminal, it printed:
Java HotSpot(TM) Server VM warning: ignoring option MaxPermSize=250m;
support was removed in 8.0
(java:5094): Gtk-WARNING **: Unable to locate theme engine in
module_path: "pixmap"
Gtk-Message: Failed to load module "canberra-gtk-module"
I'm not sure whether it's related to the error or not. Please help.
In my case I had a line
org.gradle.jvmargs=-Xmx6408m -XX:MaxPermSize=6408m -XX:+HeapDumpOnOutOfMemoryError
in my gradle.properties file in the project structure.
removing -XX:MaxPermSize=6408m from that file fixed an issue
As it was already said in this thread, Permanent Generation was removed in Java 8, which is used in your case. I think, the easiest solution is to remove parameters associated with Permanent Generation during program execution.
Go to the directory where you have Android Studio. Then go to the bin/ subdirectory. Locate the following files, which contains Java Virtual Machine options:
studio.vmoptions
studio64.vmoptions
Open these files and locate line with MaxPerSize parameter. It should look as follows:
XX:MaxPermSize=256m
Remove this line in both files. I don't know if you are using 32-bit or 64-bit operating system, so you can update both files just in case.
I'm not sure if it will solve your problem, but I would try it in such situation. In my case, with this option and Java 8, I just get the warning, but Android Studio starts anyway. After removing this parameter, Android Studio still starts, but without warning. I'm using Ubuntu 14.04 LTS.
EDIT:
There is another solution for this problem described here: https://stackoverflow.com/a/27913562/1150795.
Go to File > Other Settings > Default Project Structure > JDK location and check the path.
In case of Ubuntu Linux, we can set /usr/lib/jvm/java-7-oracle as default JDK if we are using Oracle JVM. JDK 7 is the safest option for Android.
-XX:MaxPermSize was deprecated in JDK 8, marked as obsolete in JDK 16, and removed in JDK 17. It was superseded by the -XX:MaxMetaspaceSize option.
Change -XX:MaxPermSize to -XX:MaxMetaspaceSize solve my problem.
ref:
https://github.com/expo/expo-cli/issues/4196#issuecomment-1035850918
https://docs.oracle.com/en/java/javase/17/docs/specs/man/java.html#removed-java-options
In my case opening $ANDROID_HOME/tools/lib/monitor-x86_64/monitor.ini and removing
XX:MaxPermSize=256m
from it did the job.
Oh I've solved this problem, I install Oracle JDK 9 when android studio runs on JDK 6 or JDK 7 (if I'm not mistaken).
so I uninstalled Oracle JDK 9, then download and install the JDK 7.
On MacOS the following clause in ./gradlew injects this option:
# For Darwin, add options to specify how the application appears in the dock
if $darwin; then
GRADLE_OPTS="$GRADLE_OPTS \"-Xdock:name=$APP_NAME\" \"-Xdock:icon=$APP_HOME/media/gradle.icns\" \"-Xmx1024m\" \"-Xms256m\" \"-XX:MaxPermSize=1024m\""
fi
This file can be edited by hand after the project has been generated.
i had the same issue and i was able to solve it by adding this directly in the terminal
export JAVA_VERSION=1.8
and then try the
First off, I've been trying to launch Eclipse but I kept getting the below error
Failed to load JNI shared library "C:\Program Files (x86)\Java\jdk1.8.0_25\bin...\jre\bin\client\jvm.dll"
So I looked through this thread
Failed to load the JNI shared Library (JDK)
The sensing I got was that I might want to uninstall Java and make sure I have the right 64 bit version, since I already have a 64 bit Eclipse.
I went ahead and went to uninstall the Java Update files via the control panel, which went fine.
Then when I tried to delete the Java files in my Program Files (x86) folder, I can't do it as the "file is being used by another process"
Now I can't install a new version of Java as I get an error code 1603 owing to the incomplete Java files, and I still got my JNI shared library error to fix.
I'm really stuck now. What do I do?
If you use 64 bit eclipse, you need a 64 bit operating system and 64 bit JDK. Close your eclipse and JDK, remove X86 JDK and install 64bit JDK.
ctrl+shift+esc open task manager and end all processes that are opened by java. Sometimes when you run java and your applications don't close properly, java run-time environment is still running. So you have to force java out of that state. Next time, i'd just install the newer version of java right on top of the old one. Because the installation process removes the old version of java for you and replaces it with the newest one.
with jframes using the code
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE)
this is essential to your program so it closes completely.
I've just found out that TeamCity runs on the 32-bit JVM on Windows, for some reason.
I'm seeing memory errors logged when checking out a large (not that large) Git repo and am already at the max heap size for the JVM. I know nothing about Java or the JVM, or TomCat.
How can I run TeamCity on a modern, 64-bit JVM? I sense its going to be a pain, else it would be the default.
We're a tiny team and if something doesn't have Apple levels of 'it just works' then we skip it.
We can live with this one project not be on the CI server, but it would be nice to know what's involved and weigh up the investment.
Any advice appreciated.
Edit
Okay so Markus pointed to this snippet (which I had read), but I can't see any information there explaining what to do.
Using 64 bit Java to Run TeamCity Server TeamCity can run under both
32 and 64 bit JVM. It is recommended to use 32 bit JVM unless you need
to dedicate more than 1.3Gb of memory to the TeamCity process.
If you choose to use x64 JVM please note that the memory usage is
almost doubled when switching from 32 to 64 bit JVM, so please make
sure you specify at least twice as much memory as for 32 bit JVM, see
Setting Up Memory settings for TeamCity Server.
If you run TeamCity as a service and switch to x64 bit, you will also
need to use x64 Tomcat executables, see more.
Did I miss something?
Edit 2
Ah, okay, buried in some paragraphs above that link is this:
"if you run as Windows service and want to upgrade JRE to 64 bit
version, you will need to replace \jre with appropriate
JRE"
So I guess I need to copy some files into the /jre folder?
The way I made it work (TeamCity 8, Windows server 2008 r2):
Install the 64-bit JRE on the target machine, now there are two ways to do this
A -> If you are using the Teamcity bundled JRE, replace the JRE folder ([TC Server folder]\JRE) with the JRE folder in the newly installed JRE x64 - You have to shut down the TC server service (along with all java.exe*32 services that might also use this JRE)
B -> Change the TeamCity Internal properties, to point to newly installed JRE x64 (see documentation for TC version 8, TC version 9 can be found here):
java.home=C\:\\<JRE x64 install folder>\\jre
java.ext.dirs=C\:\\<JRE x64 install folder>\\jre\\lib\\ext\;C\:\\Windows\\Sun\\Java\\lib\\ext
java.library.path=C\:\\<JRE x64 install folder>\\jre\\bin\;C\:\\Windows\\Sun\\Java\\bin\;C\:\\Windows\\system32\;C\:\\Windows\;C\:\\local\\Oracle\\clients\\112_64\\bin\;C\:\\local\\Oracle…
An alternative to point B would be to change Environment variable JAVA_HOME, it`s more simple, but it requires a Windows server restart after that
If you run the TC Server service now, it should run as a 64-bit Java process (chceck via PID in task manager) :
Don`t be alarmed if the server does not start up throwing an error :
Error: SQL error when doing: Connecting to MSSQL: I/O Error: SSO Failed: Native SSPI library not loaded. Check the java.library.path system property
Download JTDS - 1.3.1 (http://sourceforge.net/projects/jtds/files/jtds/1.3.1/) and install it
Take the ntlmauth.dll file from [JTDS-1.3.1 install folder]/x64/SSO folder and replace the one in [TC Server folder]\bin
The TC server should now run fine as 64 bit Java process
You can increase the memory allocation (as that is the whole point of the upgrade) now on the server as described here : https://confluence.jetbrains.com/display/TCD8/Installing+and+Configuring+the+TeamCity+Server#InstallingandConfiguringtheTeamCityServer-SettingUpMemorysettingsforTeamCityServer
The snippet from the updated question had a link in the original, pointing to the instructions on Java update for TeamCity server in TeamCity online doc.
Basically, the instructions vary based on the TeamCity distribution used and way of launching the server.
If your intent is to increase the memory for the TeamCity server, please make sure to read through the corresponding section on the same doc page.
Yet one more note: recent TeamCity versions perform Git fetch in a separate process and Git-related memory issues during fetch might require fine-tuning of the corresponding options.
"So I guess I need to copy some files into the /jre folder?"
No. You install a 64 bit JRE, and update the relevant setting to point at the 64-bit install's JRE.
Don't copy stuff from one JRE installation into another. You will break things!
I am running the 64-bit install of IBM Rational Application Developer (RAD) 8.0.4 on Windows 7. I have WebSphere Application Server (WAS) v6.1 running within it. To be honest, I'm not completely sure if the WAS server is 32- or 64-bit. My problems are:
Except for a few useless lines of logging at WAS startup, I get no logging in the RAD console at all. Not even when there's an exception thrown-- no strack trace, nothing. I cannot find the SystemOut.log file in the place that the WebSphere Properties dialog claims that it is. However, there is one in C:\Users\myUser\AppData\Local\VirtualStore\Program Files\IBM\SDP\runtimes\base_v61\profiles\was61profile1\logs\server1\SystemOut.log, but I do not know how to configure RAD/Eclipse to see it.
I do see an Access is Denied message as the first line of what I can see in the Console. But RAD is not clear about what or whom is being denied access, and in all other ways the server works just fine, except...
I cannot seem to get the WAS instance to run in Debug mode. If I "Restart in Debug...", RAD complies, but the server in the Servers panel of Eclipse does not show "Degugging, Synchronized"-- it simply shows "Started, Synchronized"-- just like it would if started normally. The Debug panel in Eclipse shows the server there, and claims that the debugger is listening on Port 8001. But the application will not stop on any breakpoints.
My colleagues are running identical Windows 7 machines, but have the 32-bit RAD 8.0.4, and don't seem to have this problem. I'm not ready to concede and re-install RAD down to 32-bit, nor do I have the time. There's got to be some other solution.
Work with the admin console and turn on the debug flag.
Start the server from the command line (not from within RAD) and the server would start in the debug mode.
Now try and debug a remote application (like you would any remote application within Eclipse) to attach RAD to this application Server.
Try and see if it works this way.
I would also try and see if the server is running in a debug mode (by looking for a netstat on the port 7777 which is the default debugging port)
HTH
I was able to resolve the logging by giving the LOCAL_MACHINE/Users group more permission on the file-system tree where RAD is installed (C:\Program Files\IBM\SDP\). I have found that when I run RAD "as administrator" in Windows 7, the logging problem I had went away.
Perhaps I should have done more granular analysis to figure out precisely which directory at a lower level might've needed different/more permissions, rather than changing it for all of the RAD install tree; but this works for me at the moment.
UPDATE 11.22.2013
I think the ultimate culprit was Windows 7 UAC. Apparently, applications installed within the default "Program Files" or "Program Files (x86)" directories receive extra security constraints when UAC is fully enabled. Running the server in Debug and the Console logging seem to need permission to modify things that Windows 7 feels like shouldn't be modified without elevated privileges. By either NOT installing RAD in the default Program Files or Program Files (x86) directories, OR completely disabling UAC, the problem is resolved. Disabling UAC could be considered risky, so the solution for me was to reinstall RAD outside of the default Program Files locations.