Jni plug-in in action : Screencasts part. 1

The end of google summer of code is near and before the end I wished to provide some screencasts of the plug-in I created for this time. The five screencasts are in order :

• starting a Jni debug session



• step into native code



• step into java code from native code



• go back in native code



• go back in java code

Thanks to the guy who wrote recordmydesktop software. It is the perfect tool to create screencasts.

project status, version 0.0.2 is available

The plug-in to improve debugging of Java Jni Application is available in a new version : 0.0.2
Improvements since the last version :

• Code to follow call of java methods from native code completely rewritten. The plug-in does not rely anymore on the ending lines of native functions. Less code and more reliable !
• Correction of some bugs and creation of message dialogs instead of using standard output stream.
  

• Documentation on the eclipse wiki page and advertisement on eclipse mailing lists

Some links :

• How to install the plug-in
  
• How to use the plug-in
  
• How to report a bug/ask for an enhancement
  

Eclipse tip : How to get the current debug file ?

I think its trivial for a lot of people but I have been searching for a long time in google before to found how to do it. I suppose you have the current debug thread (for instance from a debug event).

the bad way (does not work):

PlatformUI.getWorkbench().getDisplay().syncExec(new Runnable() {
public void run() {
IEditorPart ed = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().getActiveEditor();
if (ed.getEditorInput() instanceof IFileEditorInput) {
String currentDebugFile = ((IFileEditorInput)ed.getEditorInput()).getFile().getLocation().toOSString();
}
}
});

the correct way :

Object o = thread.getLaunch().getSourceLocator().getSourceElement(thread.getTopStackFrame());
if (o instanceof IFile) {
String currentDebugFile = ((IFile) o).getLocation().toOSString();
}

project status, first version of plug-in to improve the Java/JNI applications debugging to download

Since my previous post (already tree weeks) I am working hard to have some results. The problem with the breakpoints automatically added is now resolved, and the support to step from C native code to Java code implemented. This support was not so easy to add as I first thinked. Before more explanation, to not lost courageous reader of this post, I think its necessary to remind the solution I choose to step from java code into C/C++ native code.

I decided to automaticaly add a breakpoint on the first line of each native method susceptible to be called by java code. When the user selects the debug action on a native method in Java code, the plug-in stores this action. Then the C/C++ debugger reaches the breakpoint. If the last action was stepping over or return, the plug-in does a step return otherwise it does nothing.

This approach was not a good option in my point of view to follow call of Java methods from C/C++ code due to the high number of java classes (and so methods) generally present in a project. More over breakpoints are not really required, the JDT debugger will stop itself when we reach java code. The problem was to know in which case we are : Did the current C/C++ function call a java method or is the C/C++ function already terminated ?

The solution I chose is to rely on the line number of the ending line of a native function. When it is reached , the plug-in supposes that we are no more stepping in native code. I don't know if it is the best solution. Another option is to rely on the line number of the java native call.

You can install the plug-in by adding the following remote site to the Eclipse update manager : http://eclipse-incub.svn.sourceforge.net/viewvc/*checkout*/eclipse-incub/jni_seamless_debugging/update-site/site.xml

To reports bugs/enhancement there is a "org.eclipse.soc.jni" component in SOC (which is in Technology category)

To use the plugin please refer to previous posts. I will add documentation on the wiki page as soon as possible.

problems known

• sometimes gdb does not success to attach to the pid. I don't know why. Not regular and seems to be a gdb bug or limitation.
• the java files not directly in the the project do not display (see bug #198804)