I launch the following command line (process) from a Windows VC++ 6 program using CreateProcess (or _spawnv()):
java -cp c:\dir\updates.jar;c:\dir\main.jar Main
and class updates in updates.jar (overiding some in main.jar) are not read or found. It is as if the updates.jar library cannot be found or read.
If I launch the same line from a shortcut, or from the command line proper, everything IS found and executes properly.
If I launch a JVM from the command line, keep it running, AND THEN launch the executable stub (above), then everything works OK also. (This makes it look like the issue is a file rights thing).
Any insight would be greatly appreciated!
--Edward
Try using Microsoft's FileMon utility to figure out what's happening. Set the include filter to "updates" to focus in on the problem.
http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx
Have you tried this on another machine? Another OS? Which JVM are you using? Have you tried different JVMs?
Can you provide us with a minimal example which demonstrates the problem?
Thanks jdigital!
I tried FileMon and it showed me what I was doing wrong. The executable calling CreateProcess() had an unclosed file handle to updates.jar from an attempt to copy the update JAR earlier. Bad code that works in the production environment, but not in the test environment.
Related
I'm setting up LWJGL with IntelliJ - everything worked fine until I had to compile the template code. I have this error:
GLFW may only be used on the main thread and that thread must be the first thread in the process. Please run the JVM with -XstartOnFirstThread. This check may be disabled with Configuration.GLFW_CHECK_THREAD0.
I went to the edit configurations menu and did this:
What I changed it to:
This changed nothing and I'm getting the exact same error. Can someone help please?
See LWJGL "API docs" for static configuration class.
org.lwjgl.system.Configuration<T>
static Configuration<java.lang.Boolean> GLFW_CHECK_THREAD0
use a java.util.Properties properties file for command-line arguments and flags to the JVM , you only need to reference the properties file on the basic startup command line.
The problem appears to be with Mac OS requiring a special restart of the JVM because the thread may not be the first JVM thread (process) the main method is executing the code on, so it requires restart with -XstartOnFirstThread
I'm not actually familiar (vague similarity to starting my apps with a .exe i compiled) but github has a standard restart .java program to model from for that situation.
Another of that type of process.
I am using netbeans and by setting the VMoptions to:
-Djava.library.path=C:\Users\a\Desktop\temp\sqljdbc_4.0\enu\auth\x64
my program works perfect. I am trying to run the program from command line. I have tried the following but non seems to be working:
- java -Djava.library.path=C:\Users\a\Desktop\temp\sqljdbc_4.0\enu\auth\x64\sqljdbc_auth.dll
// shows the java usage
- System.setProperty("java.library.path","C:\\Users\\a\\Desktop\\temp\\sqljdbc_4.0\\enu\\auth\\x64");
// wrote it in the code but nothing is happening.
Please let me know if I am doing something wrong or there is an alternative way to do it.
Some suggestions:
Place the DLL in your Windows/<SYSTEM> folder. Make sure to place the right one (32-bit/64-bit). Then try to run it.
Make sure the DLL you are using is the right one. Your Java JRE and NetBeans JRE may be different, e.g., 32-bit JVM vs 64-bit JVM.
Eclipse froze on me earlier today, so I typed "top" into the command prompt and killed it. Now when I try to run a java application, I get this error:
eclipse\plugins\org.eclipse.jdt.debug_3.7.0.v20110509
That's all that shows up under details.
None of my previously working programs run, and I have no clue what this is. I have Eclipse 1.5.0 running 1.6 and 1.7 Java, depending on what program. Thanks for any help.
It is possible that you killed part of the process but not all of it. It is possible that a java process is running with a reference to this job. I would try restarting your computer to see if it will stop whatever process is referencing that jar.
Aside from a restart, then another option would be to use (in linux) pstree, filtered for your user to see if any other jobs are referencing that jar and/or java.
EDIT:
Another path is to look at log files. On linux they are in /var/log. Here's a link in that direction: http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-Desktop/html/felog.html
My java application which uses JNI is crashing with hs_err_pid file giving the error as "Exception Access Violation". The OS is Windows VISTA.
From what I know, my native code is illegally writing to some chunk of memory that does not belong to it.
I have used valgrind on Linux on pure native code to detect such problems in the past.
But when using java, valgrind simply fails and does not work.
What (if any) method would you suggest to identify the offending piece of code?
It is not possible for me to manually dig through the native code (few million lines) to identify it.
I was finally able to resolve the issue. I thought I will post the procedure here in case someone else is in a similar situation.
Step 1:
Build the native code with proper debugging symbols. The compiler flags could be something like "-g -rdynamic -O0".
Step 2:
The following valgrind command should do the job.
valgrind --error-limit=no --trace-children=yes --smc-check=all --leak-check=full --track-origins=yes -v $JAVA -XX:UseSSE=0 -Djava.compiler=NONE $JAVA_ARGS
In the above command, $JAVA is the java executable and $JAVA_ARGS is the arguments to your java program.
Once successfully started, it will take orders of magnitude more time to complete the execution. Valgrind will print thousands of errors (most related to jvm which can be ignored). You can however identify the ones that relate to your jni code.
This general strategy should be applicable to most native memory related problems.
If you are running Java under Linux, you could use the -XX:OnError="gdb - %p" option to run gdb when the error occurs. See this example.
Under windows, you can use the -XX:+UseOSErrorReporting option to obtain a similar effect.
For debugging JNI code a method posted in this article could be useful (it's about debugging JNI using Netbeans and Visual Studio). It's simple - just start your Java program, then in Visual Studio pick Debug -> Attach to process and choose java.exe process running your program.
When you add breakpoints to your C++ code, Visual Studio will break on them. Voila :)
In an application I am writing, I am launching another application (a runnable JAR) using Runtime.exec(...). Everything launches successfully in Windows, but Linux (specifically certain installations of CentOS - works in Ubuntu) has been giving me some problems. For some reason, the only way the secondary application will successfully launch is if I execute the first through a terminal. All behavior works as expected. However, if I launch the first application by double-clicking its icon (without a terminal open), the button to launch the second application seems to do nothing. I get no exceptions or error output - just a flash of my progress bar saying that it is launching, and then nothing. I can confirm through jconsole that the second application's process is never launched.
I have seen the commonly linked article on the pitfalls of the exec method ( http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html ), but have not been able to solve this problem with anything I have found there. I am in fact reading the output and error streams of the second process, as I see all output when it successfully runs (after launching the first application through a terminal command). Not knowing a lot about deeper workings of Linux, I think this sounds like it may be a permissions issue with the output stream or something, but I am not sure.
In case it helps to diagnose the problem, I am using the command:
rt.exec(new String[]{"\bin\bash", "-c", "java -jar myjarfile.jar myArg1 myArg2 ..."}); Since this works (depending on how the application is launched), I'm not too concerned that anything is wrong with this piece of code...
Anyone have any suggestions? Thanks in advance!
EDIT: The solution was to fix the directory to the JAR I was attempting to run. When launched via the GUI, user.dir was pointing to the parent directory of the folder containing my application. Since I'm using Eclipse RCP, my solution was to use
String currDirPath = Platform.getInstallLocation().getURL().toString(); instead. Thanks for the help everyone!
Since you're just using the jar file name - myjarfile.jar - and not the full path to it, depending on the current working directory, the jar may or may not be found. Try changing your exec command to use the full path to the jar instead. You can debug this by using rt.exec() to write the output of 'pwd' to a text file.
instead of
rt.exec(new String[]{"\bin\bash", "-c", "java -jar myjarfile.jar myArg1 myArg2 ..."});
use
rt.exec(new String[]{"\bin\bash", "-c", "/***path to java***/java -jar myjarfile.jar myArg1 myArg2 ..."});