I faced strange problem in Sonar (code analysis tool) and do not understand why it is faile. It is started using command line:
%JAVA_EXEC% %SONAR_OPTIONS% -cp "%SONAR_RUNNER_HOME%\lib\sonar-runner-dist-2.3.jar" "-Drunner.home=%SONAR_RUNNER_HOME%" "-Dproject.home=%PROJECT_HOME%" org.sonar.runner.Main %*
I am not Java programmer, but I would like to debug this process somehow. I know that error appears inside one of loaded plugins, not inside sonar itself.
Question: is there way to start java application with debugging availability without eclipse and any other special and very massive editor? Something command line'ed with ability to set breakpoint, inspect variable value and stepping forward/stepping over is enough for me.
There's JDB, the Java Debugger from the official SDK.
Simply add this parameter to invoked command and connect to this process with prefered debugger (Eclipse, IntelliJ or what you want)
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
You can debug this remotelly!
Related
I can't get multiple threads to run using JOMP no matter what I try. I actually can't run a JOMP program from the command line no matter what I try either in fact, although ironically it will compile from there and then run in Eclipse! Even in Eclipse though I only have one thread. I've been through the notes from my university course about installation of JOMP carefully, but they have not helped. I'll be more specific though:
Items in quotes below are from those notes:
"There are a couple of websites that tell you how to make jomp run under Eclipse, see http://www.lst.inf.ethz.ch/teaching/lectures/ss10/24/ assignments/assignment_10/eclipse.txt"
This refers to a now broken link. It also seem to be the only link anyone on forums like Stackoverflow refer to when talking about this issue. Apparently it has instructions on runtime settings for Eclipse to allow multiple threads to run, but since the link is currently broken I can't access those valuable instructions.
"All that is required in order to do that is to ensure that jomp1.0b.jar is on the CLASSPATH"
I ran echo %CLASSPATH% at the command prompt to check if it was on the class path and got the following response:
C:\Program Files\Java\jre1.8.0_162\lib\jomp1.0b.jar
On my PC the jomp jar file is in that folder, so it appears I should be able to execute compiled JOMP programs from the command line, but unfortunately that is not the case. By executing one of these commands it should run:
java −Djomp.threads=2 parallel
java −Djomp.threads=2 -cp . parallel
java −Djomp.threads=2 -cp C:\Users\terry\eclipse-workspace\JOMPHello\src parallel
This is the folder the jomp, java and compiled class files are in. I also checked if "parallel" is the fully qualified class name in the way I have set it up in Eclipse, and it does appears to be. So running one of these commands should allow me to run the jomp program from the command line as near as I can tell, but they all return the following error:
Error: Could not find or load main class parallel
Caused by: java.lang.ClassNotFoundException: parallel
(To which I feel like telling Java, "You're not looking hard it enough! It is right in the folder I am running this command from!")
Clearly I am missing something. Can anyone tell me how to get JOMP programs running on the command line, or alternatively knows where there are accessible instructions for how to set up the work around runtime settings in Eclipse?
My implementation of the program seems to run with only one thread, so hopefully that means it is correct, but I can only be sure once I have run it with at least a few more threads.
Thanks,
Terry.
I figured out how to set up the runtime argument in Eclipse. You just have to add the following line into the VM Arguments box in under the Argument tab in Run Configurations for the file:
−Djomp.threads=n
(where n as before is the number of threads you want).
I'd still like to know why it's not working on the Command Line though. It makes me think my Java is set up weirdly.
I have a .sh file which runs independently on Linux server to sync some data but now there is some problem with the sync so I wanted to run this .sh file in debug mode in eclipse so that I can check my java code where the problem is?
Is there any plugin or options available in eclipse to do this.
Please let me know if you need any further information.
If you want to debug your java code which your shell script invokes, just write a wrapper java code which invokes your main java code, and you can easily debug using eclipse.
What is the content of this .sh file? Is it running a JAR?
If so, you can remotely debug a java code. The following blog explains using screenshots: http://javarevisited.blogspot.co.uk/2011/02/how-to-setup-remote-debugging-in.html
I don’t think we can use shell script debugger in the Java debugger session. i.e you need to debug java code and shell script code separately in separate debug sessions.
You can use basheclipse to debug shell script, this will only work with shell script editor ShellEd.
Also check the open tickets for debugging in ShellEd.
Note
Outside eclipse you can try http://bashdb.sourceforge.net/
Setup:
I am working on a Java project which invokes some Perl scripts.
Problem:
If I run the Perl script from terminal, it works fine. But when I invoke the same Perl script with same arguments from Java code, it fails. It is an extremely strange and annoying bug.
I am able to debug Perl in Eclipse using EPIC plugin. And of course, I can debug Java code. It would be helpful to debug Java and Perl code in the same debug session in Eclipse, so that I can see whats different happening when the script is invoked via Java code.
Not sure if this is even possible, but if anyone has any idea, please share.
Thanks.
Perl has some remote debugging capabilities, so you can get what you need, I think. I don't use EPIC, so I don't know if you'll be able to do it all within Eclipse.
Set the environment variable named PERLDB_OPTS to have the value RemotePort=<host>:<port>. Then, start Perl with the -d flag. Instead of the debugger trying to interact with standard IO on the invoking terminal, it will attempt to connection to host:port.
Here's a Unix-y example. I've got a Perl script hello.pm and two terminal windows open.
First terminal
$ nc -l 12345
That's started NetCat as a dumb server listening on port 12345. If you don't have a server listening before Perl starts, it won't work.
Second terminal
$ export PERLDB_OPTS=RemotePort=localhost:12345 # set the env variable
$ perl -d hello.pm
Now the script is running. Back on the first terminal, I see
First terminal
main::(hello.pm:1): print "hello\n";
DB<1>
I'm in the Perl debugger and ready to go!
I know that at least the Komodo IDE has support for remote debugging, and there's a Perl Monks post on doing it with Emacs, so you can get something more than the command line even if it's not Eclipse. Good bug hunting!
If I run the Perl script from terminal, it works fine. But when I invoke the same Perl script with same arguments from Java code, it fails.
I suggest that you check that you are running the same version of Perl in the two "contexts"; i.e. when the Perl app is run from the command line and from Java.
If that's not the problem, check the environment variables.
The other approach to solving this problem would be to focus on why the program is going wrong, not on how / why the contexts are different. Look at the evidence that you have, and look at ways to gather more evidence ...
The potential problem with trying to do this using a Perl a debugger (in an IDE or stand-alone) is that you are actually running Perl in third "context" which might be different from either or both of the existing ones.
Using a debugger may work ... or it may leave you even more confused.
I have a single application which will cause eclipse itself to hang when run via eclipse. If I export this application as a jar and run it it works fine. But if I run (or debug) it the application will appear to start (according to ps) and run; but eclipse itself will hang, and is reported as a 'stopped' program with no CPU or memory usage. I've placed a breakpoints on the first line of this application and it doesn't even get there before eclipse ends up stopped. If I forcefully wake eclipse out of stopped state it will work; but it will also lose it's connection with the program I started. My program I want to debug will continue running but eclipse can't control or kill it after I resume the stopped eclipse.
I can run plenty of other applications without issue from eclipse. Oddly I had this issue before, then I could run my application for a day, and now I'm back to the original issue. I don't know what changed between those that would matter.
Can anyone suggest what may cause this or how to repair it?
UPDATE:
I did some more linux magic. It seems that eclipse is stopped while waiting for the command:
sh -c stty -lcanon min 1
It also seems that before that there was a sh (defunct) command which also hung without being reaped for a few minutes which I think was keeping eclipse from running properly; the sh (defunct) finally goes away if I wait long enough; but then the sh command I just linked comes up. I don't know what the original defunct SH command was; I can't do ps fast enough to catch it before it goes defunct. Both issues occur only with eclipse; as a jar file this program runs perfectly fine.
My running assumption is that eclipse isn't getting or handling the sigchild correctly? that would explain the sh (defunct) application at least. It doesn't explain the current SH command which doesn't show as defunct; despite it being something that should execute in seconds?
UPDATE 2.0:
I found this link: http://linux.about.com/od/srl_howto/a/hwtsrl13t04_3.htm basically stty is known to hang when it uses the < /dev/tty syntax; which is why the syntax is deprecated and replaced with a newer syntax. I'm pretty sure this is the problem. Sadly I have no way of figuring out what library is using the deprecated command. I think this all started with the ConsoleReader being constructed; but who knows what code actually ran the command that freezes? also, it seems if this was that broken anyone running consoleReader from eclipse on a linux environment would have the same problem; which I think is safe to assume isn't the case or it would be documented all over the net; so maybe my understanding is still off?
It is related to the configuration of the stty process that is created to attach the console and hence will occur only on UNIX like systems. Seems fixed on current 2.11 jline version.
To bypass the problem you can disable the special unix-terminal capabilities using:
-Djline.terminal=none
as VM argument on the eclipse launch configuration.
Try increasing -Xms<abc>m/-Xmx<efg>m (depending on the system memory) on eclipse.ini in the root directory of eclipse installation.
The problem was that we were using an older version of 'jline' which used deprecated functionality. The new jline jar fixed the problem, as it no longer used the deprecated stty calls. I'm not quite certain why eclipse caused this to happen every time; it seems as if it should be an intermittent error, but jline was definitely the cause.
I am using Jline2 framework to build a console application in Java. When launching the application from Eclipse on Windows 7, the shell exists immediately and does not wait for the user to input commands.
Any idea on what might be wrong?
Finally found a small trick to make it work. Add the following VM option to the execution parameters (Run Config/Debug Config)
-Djline.terminal=jline.UnsupportedTerminal
This will make the code run inside Eclipse. However, some strange characters may be written to the console during the course of the run.
Hope this helps.
If you are using picocli with jline2.
You can delegate the heuristic to picocli which seems better than the jline2 heuristic (instead of using -Djline.terminal=jline.UnsupportedTerminal)
The code can looks like :
// JLine 2 does not detect some terminal as not ANSI compatible, like Eclipse Console
// see : https://github.com/jline/jline2/issues/185
// So use picocli heuristic instead :
if (!Help.Ansi.AUTO.enabled() && //
Configuration.getString(TerminalFactory.JLINE_TERMINAL, TerminalFactory.AUTO).toLowerCase()
.equals(TerminalFactory.AUTO)) {
TerminalFactory.configure(TerminalFactory.NONE);
}
(see https://github.com/jline/jline2/issues/185)