Thursday, August 30, 2007

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.

Friday, August 10, 2007

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 :

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();

Thursday, August 2, 2007

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 :*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)