Disclosure: I'm not super familiar with Java, so if anything rings untrue below, please point out
I'm trying to run some microbenchmarks with Caliper for instrumented code, with an instrumented JRE.
I set my JAVA_HOME to point to the instrumented JRE, (so that $JAVA_HOME/bin/java is appropriate). I setup various options using $JAVA_TOOL_OPTIONS (including a bootclasspath and javaagent).
I then run caliper as I usually would (which when using a non-instrumented JRE works fine), and I keep getting the following exception
An exception was thrown from the benchmark code.
java.lang.RuntimeException: failed to start subprocess
at com.google.caliper.Runner.measure(Runner.java:278)
at com.google.caliper.Runner.runScenario(Runner.java:229)
at com.google.caliper.Runner.runOutOfProcess(Runner.java:378)
at com.google.caliper.Runner.run(Runner.java:97)
at com.google.caliper.Runner.main(Runner.java:423)
Caused by: java.io.IOException: Cannot run program "java" (in directory "extra/"): error=2, No such file or directory
I've tried making sure the $JAVA_HOME/bin/ is first in $PATH, tried symlinking $JAVA_HOME/bin/java to the current working directory, but all to no avail.
Anyone have any suggestions? I've probably spent upwards of 5 hours trying to work through this one...
[EDIT]
So I think this might be a broader question, focusing on the instrumented JRE. I ran a simple test, where I create a ProcessBuilder that just runs ls. It works fine with non-instrumented java, but fails with the instrumented version, with the same kind of error (error=2). Any suggestions?
The issue was not with caliper, or broader instrumented JREs, but rather I had not chmod +x jre/bin/* and chmod +x jre/lib/*. After that, the issue was resolved.
Related
When I try to run a code snippet in Java Scrapbook, Eclipse cannot start the VM with the following error:
Unable to launch scrapbook VM
Exception occurred executing command
line.
Cannot run program "C:\Program
Files\Java\jdk-14\bin\javaw.exe" (in directory "C:\tmp"):
CreateProcess error=206, The filename or extension is too long
There was a bug report in Eclipse's Bugzilla, but it was closed without a satisfactory answer.
The other similar answers on SO have different causes:
Starting in directory with an unusual name
Starting in an Android project
I tried changing the working directory to C:\tmp so that any issues caused by directory structure are solved, but to no avail.
Environment: OpenJDK 14, Eclipse 2020-06, Maven project
The actual problem is that Windows cannot start a program whose command line is longer than about 32000 characters. This can happen if you have so many dependencies that the command line arguments reach the limit. This is why changing the directory to C:\tmp did not help, the size of this part is negligible when compared to all the dependencies on the command line.
There's a nice answer to a different question which contains some useful tips which can help out.
I initially worked around the issue by running the code snippet in a newly-created project, but this was only possible because I did not need any parts of the project I'm working on.
The real solution was to switch to Linux because pretty much all distributions have limits which exceed those of Windows by an order of magnitude or more.
I'm having quite a bit of trouble with ./gradlew. I am trying to make a 1.14.4 mod, and have been having a lot of problems with gradle, but I've finally got gradle working (an error in my build.gradle code). I'm on a Mac, and my friend (with whom I am building the mod) is not, and running
./gradle wrapper
works fine on his computer but not on mine. It must be a system issue, but I'm really not sure. The error I keep getting is:
Could not create service of type ScriptPluginFactory using BuildScopeServices.createScriptPluginFactory().
> Could not create service of type FileHasher using BuildSessionScopeServices.createFileSnapshotter().
I've looked online, and all of the work-arounds I have found doesn't help me. Running ./gradlew wrapper with --info I get this. Running with --stacktrace, I get this. Finally, with --debug I get this. I don't know if these are helpful (I'm sure they are, if you know what to look for).
Any insights into what on earth is causing this is greatly appreciated!
P.S.: my made-up username in the pastebin links is drdeducer :)
P.P.S.: it isn't just ./gradlew wrapper that doesn't work; it is ./gradlew <anything>—even just ./gradlew!
Found the problem for me. In the process of trying to initially get gradle working, I added touch ~/.gradle/gradle.properties and specified org.gradle.java.home=/Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home. Typing /usr/libexec/java_home -V you will get a list of your Java versions, so in my local gradle.properties, I had to specify a Java version less than 11 (it ended up being open adoptopenjdk-8.jdk). To see Java versions, type brew search java, and then brew cask install <desired java version> (for mac users).
Background: Ubuntu 64bit machine. I need to call a matlab-based jar from django(deployed on apache). Here is the problem, when I run the command on the shell, it works; however, when I call subprocess.Popen({{cmd}}) inside django code, an exception is thrown.
Edit: I try to open a python shell and call subprocess.Popen({{cmd}}). I write a single python script file and put the same code in it. They all work. It's so weird that the code just fail when run on django!!!!!!
For details:
The cmd: java -jar A.jar param1 param2 param3 param4
When run directly in shell, everything is normal. When run with python code, the exception is:
Exception in thread "main" java.lang.ExceptionInInitializerError
at com.mathworks.toolbox.javabuilder.internal.MCRConfiguration.getProxyLibraryDir(MCRConfiguration.java:178)
at com.mathworks.toolbox.javabuilder.internal.MCRConfiguration$MCRRoot.get(MCRConfiguration.java:77)
at com.mathworks.toolbox.javabuilder.internal.MCRConfiguration$MCRRoot.<clinit>(MCRConfiguration.java:87)
at com.mathworks.toolbox.javabuilder.internal.MCRConfiguration.getMCRRoot(MCRConfiguration.java:92)
at com.mathworks.toolbox.javabuilder.internal.MCRConfiguration$ModuleDir.<clinit>(MCRConfiguration.java:66)
at com.mathworks.toolbox.javabuilder.internal.MCRConfiguration.getModuleDir(MCRConfiguration.java:71)
at com.mathworks.toolbox.javabuilder.internal.MWMCR.<clinit>(MWMCR.java:1466)
at autoBlockJava.AutoBlockJavaMCRFactory.newInstance(AutoBlockJavaMCRFactory.java:83)
at autoBlockJava.AutoBlockJavaMCRFactory.newInstance(AutoBlockJavaMCRFactory.java:94)
at autoBlockJava.AutoBlockJavaSharedMCRFactory$3.call(AutoBlockJavaSharedMCRFactory.java:95)
at autoBlockJava.AutoBlockJavaSharedMCRFactory$3.call(AutoBlockJavaSharedMCRFactory.java:93)
at autoBlockJava.AutoBlockJavaSharedMCRFactory.getInstance(AutoBlockJavaSharedMCRFactory.java:72)
at autoBlockJava.AutoBlockJavaSharedMCRFactory.newInstance(AutoBlockJavaSharedMCRFactory.java:93)
at autoBlockJava.manualMain.<init>(manualMain.java:97)
at autoblock.AutoBlock.main(AutoBlock.java:29)
Caused by: java.lang.NullPointerException
at com.mathworks.toolbox.javabuilder.internal.MCRConfiguration$ProxyLibraryDir.get(MCRConfiguration.java:143)
at com.mathworks.toolbox.javabuilder.internal.MCRConfiguration$ProxyLibraryDir.<clinit>(MCRConfiguration.java:173)
... 15 more
I'm totally confused. I really don't know what's the reason for it now.
I think your problem has nothing to do with Python, Django, or Java, but only with the way Matlab calls external programs.
On Linux, Matlab sets the variable LD_LIBRARY_PATH in the environment of child processes. As an example, on my system:
>> getenv('LD_LIBRARY_PATH')
ans =
/opt/MATLAB/R2013a/sys/os/glnxa64:/opt/MATLAB/R2013a/bin/glnxa64:/opt/MATLAB/R2013a/extern/lib/glnxa64:/opt/MATLAB/R2013a/runtime/glnxa64:/opt/MATLAB/R2013a/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/opt/MATLAB/R2013a/sys/java/jre/glnxa64/jre/lib/amd64/server:/opt/MATLAB/R2013a/sys/java/jre/glnxa64/jre/lib/amd64
Apparently, this setting makes some system libraries (or just the correct version of glibc?) unavailable to child processes:
>> !konsole
konsole: /opt/MATLAB/R2013a/sys/os/glnxa64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /usr/lib/libstreamanalyzer.so.0)
konsole: /opt/MATLAB/R2013a/sys/os/glnxa64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /usr/lib/libstreams.so.0)
The problem can be resolved by explicitly unsetting LD_LIBRARY_PATH by
setenv('LD_LIBRARY_PATH')
I'm not sure for what purpose Matlab sets LD_LIBRARY_PATH, and I'd guess that some special functionality must be broken by unsetting it. However, I've had the line above in my startup.m for years now, and I haven't run into any problems.
See also: Start application from Matlab
I have a simple jar application that works properly when double-clicked directly, but crashes when run as a .app.
The Mac console/system error application shows an Exited with code 1 which means there's an error.
I tried adding the WorkingDirectory key/value to the plist as recommended by another stackoverflow question (cant find it again... hmm), however that didn't work.
I'm trying to find a way to capture the errors/stacktrace so I know what the actual problem is, and not just shooting in the dark.
Update #1
After much digging, I found a way to execute the java portion with some debugging:
$ export JAVA_LAUNCHER_VERBOSE
$ ./YourApp.app/Contents/MacOS/JavaApplicationStub
This allowed me to discover that the main class path was incorrect in my POM. Such a silly mistake.
However, while opening the application works with the above command, launching the .app with a double-click gives an error -600
Well, seems I've worked this out myself.
Doing the following allowed me to see the stack trace, which led me to the fact that my <mainClass> for mac app bundle plugin was incorrect.
$ export JAVA_LAUNCHER_VERBOSE
$ ./YourApp.app/Contents/MacOS/JavaApplicationStub
The eventual -600 error I was getting was cleared away by doing a mvn clean and mvn package.
I'm trying to learn Java and I'm having problems with the appletviewer command. I am using openSUSE 11 and am able to compile and run normal java programs but when I issue the appletviewer command I'm getting the following error "bash: appletviewer: command not found".
I have set the PATH variable in the .bashrc file. so the problem is not that of the path. This can also be verified from the fact that javac and java commands are working normally. I have googled and tried many said resolution but none is working. I have even tried moving the files to the bin folder and running the command from there.
So what may the cause of this? Isn't appletviewer designed to work in linux? And FYI I have replaced the OpenSDK and IcedTea versions with the jdk1.6.0_14 version from the sun site. Please help.
Thanks
Chris
As a test, do the following:
$which java
$which appletviewer
Check to see if the paths are different. If the second command gives no output, appletviewer may not even be installed (or can't be located by your system).
You need to install java-1_6_0-sun-devel-1.6.0.u14-0.2.1
$ sudo zypper install java-1_6_0-sun-devel
You will find it in the openSUSE-11.1-Non-Oss repository.