I am testing some custom JNI code on a remote Linux based system. I don't want to have to install DBX and JDB isn't being entirely helpful and diagnosing the issue. Is there any other light weight java JNI debugger that will actually show me where within the JNI code Im going wrong?
Thanks
In case of native code, you have to use gdb or anything else that is available. After all, once in JNI, you are debugging native code. It's no longer Java.
Related
I have a Java application that uses a C++ DLL via JNA. The C++ DLL is proprietary, therefore, I cannot share the code unless I can make a simplified reproducible example. It is not straight forward to make a reproducible example until I further debug.
The application crashes sporadically with the error message Java Result: -1073740940. I am running the Java application from Netbeans, although it crashes without Netbeans. Since there is no hs_err_.log, I guess crash is in the C++ layer. How can I begin debug this crash?
The "Java Result" output from Netbeans simply tells you the exit code of the java program. You could generate the same with a System.exit(-1073740940);. A successful program exits with a code of 0. Anything else is a failure that requires documentation to interpret.
You have not given us any indication what DLL you are using, so the only information we have to work with is this exit code. Converting that int to hex digits results in 0xc0000374 which you can enter into your favorite search engine and find out is a Heap Corruption Exception. Some examples are provided but in general this means you are accessing non-allocated native memory.
Without having any idea what code you're using, I would guess you're doing something wrong with native memory, invoking native functions, or incorrectly manipulating pointers or handles somewhere in your application.
You should start by looking closely at arguments to native functions. Type mapping could be a problem if the number of bytes is mismatched. Investigate any Pointer-based arguments to native functions, including ByReference arguments. Trace back in the code and find when/how these Pointers were associated with native-allocated memory. If it was never allocated, that's one possibility for the problem. If it was allocated, see if you can find a point where that memory was freed, possibly by a different native function.
The root cause of the crash was heap corruption in the C++ layer. If a random crash occurs due to heap corruption, sometimes, it is complicated to pinpoint the cause of crash because the crash can happen later, when the program tries to manipulate the corrupted memory. Hence, it is also complicated to provide an SSCCE, especially when we work on the proprietary legacy code.
How I debugged this crash:
Reproduction: Try to find a consistent use case for the crash. If the crash is random then try to figure out a set of user actions that always leads to the crash.
Assumption: Guess which feature/component contains the crash.
Validation: Make sure that crash is not happening when you disable this feature/component.
Verification: Skimm through and slice the code. Review the small piece of code.
Documentation: Write everything.
Daniel's answer was very helpful in fixing this crash!
I would like to print the stacktrace of native methods calls of a Java application. The Thread.dumpStack() is only printing java methods calls.
If you want the non-java stack, you need a "native" debugger, e.g. gdb.
You can attach to your running java with gdb, too.
For documentation on seamless debugging of Java with gdb, see also: http://gcc.gnu.org/java/gdb.html
(gcc can compile java code to native code; at which point the native debugger will also show Java backtraces.)
If it is OK to do it outside of your application you can run $JAVA_HOME/bin/jstack -m <jvm_pid>
To view the internal JVM (C-level) function calls, attach a standard C debugger to the process.
Exactly how to do this does depends on your OS and debugger of choice, for example on OSX one would use xcode. Instructions for using gdb can be read here.
Is there any debugger that helps debug a Java JNI program along with the C library?
I should be able to debug the program starting from static void main in Java and continue to debug and place break points in the native c function and then continue to debug in Java after the control is transferred from C to Java.
A Java Virtual Machine debugger is very different from native code debugger. There is currently no such MATURE solution as one and the same debugger which would be able to seamlessly step from Java to native code and back. While this is a very irritant problem which makes some smart people trying to develop such a solution, there is undoubtely tons of un-imaginable problems involved. I personally do it in the following way:
start your Java code in debug mode and put a breakpoint at the first native call you are interested in. You can even implement a static native call, which won't do anything significant but will enable you to break as soon as possible.
fire up a native debugger. This absolutely can be the same instance of Eclipse, given two prerequisities: you have CDT installed and your native code was compiled in a way, that the debugging info is understood by CDT. Attach to the java(w.exe) process running your Java code. Put a breakpoint in the native code.
Whenever you need to transition over JNI interfaces, put breakpoints as close to the call entry/exit as you can (or need).
I have found that running the java code in an IntelliJ IDEA debugger and setting a very early break point allows one to attach CLion's debugger to the process (after sudo echo 0 > /proc/sys/kernel/yama/ptrace_scope). Then each IDE will stop the JVM and raise it's window at it's respective brake points in either Java or JNI Native code, with inspection of objects in memory in which ever context stopped. This makes for a fairly smooth experience.
I have a fairly complex Java application that is utilizing a lot of CPU, and would like to know if there is any recommendation on a profile tool that I could use to determine the cause of the CPU utilization. My goal is to pinpoint the location in the code where it is using most of the CPU time.
I've used jProfiler and YourKit on Linux. But you might find the information you're looking for by running the jconsole that comes with recent JDKs. Good information on how to use it: http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
Netbeans has good built-in profiler. NB runs quite well on Ubuntu 9.10
If your issue cannot be observed in developement, you can attach the profiler to a remote JVM (your production environment). You have to configure the host JVM to accept the JMS/JConsole connections from the profilers. The JMS/JConsole realtime monitoring visualization charts look pretty awesome.
I have used Visual VM in the eclipse IDE. If you are not on an IDE, jhat and jconsole will help. Google jhat for more info
If you are comfortable with Eclipse, I'd recommend TPTP.
If you use Sun Java 6 then learn to use jvisualvm in the JDK on the machine running the troublesome program.
It will answer most of your questions, can attach effortlessly to an already running program and is gratis.
This method is low-tech but works best. Here's a short explanation why.
Since you are not running under an IDE, you can use pstack or lsstack to get stack samples. If the app is using lots more time than it should, then most likely the problem is one or a few rogue function calls, which will be clearly visible on most of the stack samples.
I'd like to install Java on a Psion 5MX with GNU/Linux 16MB RAM machine, will it be possible?
Unfortunatly, "KVM must be installed by the manufacturer".
What I want is to be able to is to write basic Java code, test and sketch simple algorithms.
Important notes: I don't need the graphic part since I'll only use the console (no graphic server) but this will be inside a Debian.
There is a List of Java virtual machines on Wikipedia, with a number of them open source and targeting embed devices. Like Mika which seems quite small and portable.
Please give us more details about the machine, besides the OS and the memory. Also give us details on what you hope to accomplish with Java on such an underpowered machine (Java has some big overhead in embedded places as compared to writing native code).
The answer is maybe. I've seen Java running on a machine with 4MB of RAM, but it was not running Linux (in fact there was no OS at all). Link: Java on the Nintendo DS
The Squawk virtual machine is designed for small devices. It's probably got sub-par performance though since most of it is in java.
Probably a little late but I'd also suggest Squawk. It runs on sun spot devices which have 160k of membory (or something in that area). 160mhz CPU. The whole JVM is open source so you can try to re-write it for your own devices :)