Debugging

Debugging code running on the JNode platform is no easy task. The platform currently has none of the nice debugging support that you normally find on a mature Java platform; no breakpoints, no looking at object fields, stack frames, etc.

Instead, we typically have to resort to sending messages to the system Logger, adding traceprint statements and calling 'dumpStack' and 'printStackTrace'. Here are some other pointers:

  • If you are debugging a JNode command, you may be able to use ShellEmu or TestHarness to run and debug JNode specific code in your development environment. (This may not work if your command makes use of JNode specific services.)
  • A lot of classes have no JNode platform dependencies, and can be debugged using JUnit tests running in your development sandbox.
  • If you are debugging low-level JNode code, you can use "Unsafe.debug(...)" calls and the (so called) Kernel debugger to get trace information without causing object allocation. This is particularly important when debugging the JNode memory management, etc where any object allocation could trigger a kernel panic.
  • Beware of the effects of adding debug code on JNode system performance, and on timing related bugs; e.g. race conditions.

There is also a simple debugger that can be used in textmode to display threads and their stacktraces. Press Alt-SysRq to enter the debugger and another Alt-SysRq to exit the debugger. Inside the debugger, press 'h' for usage information.

Note: the Alt-SysRq debugger isn't working at the moment: see this issue.

Sending logger output to the serial port

If you need to see logger output on the serial port, try the following hack:

  1. Edit "org.jnode.log4j.config.Log4jConfigurePlugin" to set LOG_TO_KERNEL_DEBUGGER to true.
  2. Build JNode
  3. Run JNode with the "kdb" boot option.

All DEBUG and higher messages sent to the logger will also be written to the serial port using "Unsafe.debug()". Note that this will mess up the console and dramatically slow down anything that writes log messages.

Trouble-shooting int_die_halt

Make a note of the EIP register, and try cross-referencing it with the file jnode\all\build\x86\bootimage\bootimage.lst (the lines starting with the $ sign).