How to interpret the bricks run time error codes

This is where you talk about the NXJ hardware related topics such as the brick, sensors, LEGO pieces, etc.

Moderators: 99jonathan, roger, imaqine

How to interpret the bricks run time error codes

Postby calamity » Sun Dec 14, 2008 12:09 pm

I would like to know how the nxt brick's run time error codes are interpreted. For example:

Class: 8
Method 17
PC: (I cannot recall the number)

In cases so far, I've been able to spot in the code the error myself. However, as I build more complex Java code, I fear that I will have more difficulties spotting the run time errors.

I'm guessing that the nxt uses some scheme to number the classes and methods. That class and its method is the one that threw the error.

Any help would be greatly appreciated.

Thank you.
calamity
New User
 
Posts: 20
Joined: Sat Nov 29, 2008 11:06 pm

Postby ChrisB01 » Sun Dec 14, 2008 4:55 pm

I found this in the sticky faq thread in the software section. Looks like you had a null pointer exception.

Chris

OBJECT 0
THREAD 1
STRING 2
THROWABLE 3
ERROR 4
OUTOFMEMORYERROR 5
NOSUCHMETHODERROR 6
STACKOVERFLOWERROR 7
NULLPOINTEREXCEPTION 8
CLASSCASTEXCEPTION 9
ARITHMETICEXCEPTION 10
ARRAYINDEXOUTOFBOUNDSEXCEPTION 11
ILLEGALARGUMENTEXCEPTION 12
INTERRUPTEDEXCEPTION 13
ILLEGALSTATEEXCEPTION 14
ILLEGALMONITORSTATEEXCEPTION 15
THREADDEATH 16
ChrisB01
Advanced Member
 
Posts: 189
Joined: Sat Mar 15, 2008 12:19 pm
Location: UK

Postby gloomyandy » Sun Dec 14, 2008 6:58 pm

Hi,
Here are a few notes on debugging in a leJOS environment that you may find of some use...

When you link your program using the leJOS linker add the -v (verbose option)... You should see some output like this...
Code: Select all
clean:
compile:
Compiling 1 source file to H:\Lego\java\hstest
link:
Class 0: java.lang.Object
Class 1: java.lang.Thread
Class 2: java.lang.String
Class 3: java.lang.Throwable
Class 4: java.lang.Error
Class 5: java.lang.OutOfMemoryError
Class 6: java.lang.NoSuchMethodError
Class 7: java.lang.StackOverflowError
Class 8: java.lang.NullPointerException
Class 9: java.lang.ClassCastException
Class 10: java.lang.ArithmeticException
Class 11: java.lang.ArrayIndexOutOfBoundsException
Class 12: java.lang.IllegalArgumentException
Class 13: java.lang.InterruptedException
Class 14: java.lang.IllegalStateException
Class 15: java.lang.IllegalMonitorStateException
Class 16: java.lang.ThreadDeath
.... lots more classes
Method 0: Class: java.lang.Object Signature: <init>()V PC 4257 Signature id 2
Method 1: Class: java.lang.Object Signature: notifyAll()V Native id 5
Method 2: Class: java.lang.Object Signature: wait()V Native id 6
Method 3: Class: java.lang.Object Signature: wait(J)V Native id 7
Method 4: Class: java.lang.Object Signature: toString()Ljava/lang/String; PC 4258 Signature id 100
Method 5: Class: java.lang.Thread Signature: init(Ljava/lang/String;Ljava/lang/Runnable;)V PC 4261 Signature id 102
Method 6: Class: java.lang.Thread Signature: <init>()V PC 4304 Signature id 2
Method 7: Class: java.lang.Thread Signature: run()V PC 4316 Signature id 1
Method 8: Class: java.lang.Thread Signature: start()V Native id 9
Method 9: Class: java.lang.Thread Signature: yield()V Native id 10
Method 10: Class: java.lang.Thread Signature: sleep(J)V Native id 11
Method 11: Class: java.lang.Thread Signature: currentThread()Ljava/lang/Thread; Native id 12
Method 12: Class: java.lang.Thread Signature: getPriority()I Native id 13
Method 13: Class: java.lang.Thread Signature: setPriority(I)V Native id 14
Method 14: Class: java.lang.Thread Signature: isDaemon()Z Native id 19
... lots more methods
Master record    : 16 bytes.
Class records    : 45 (450 bytes).
Field records    : 101 (101 bytes).
Static fields    : 51 (102 bytes).
Static state     : 51 (200 bytes).
Constant records : 68 (272 bytes).
Constant values  : 68 (766 bytes).
Method records   : 203 (2436 bytes).
Exception records: 85 (680 bytes).
Code             : 163 (10003 bytes).
Total            : 15027 bytes.


You can then use this to decode the exception code display. The class will be the class of the exception and should match one of the numbers in the class list... The method number will tell you which method the error occurred in and finally the PC can be used to compare against the PC of the start of the method and the start of the next method to give you some idea about the actual location of the error. If you are feeling very brave you can even use something like the Java disassembler jad to decompile the class file and from this work out the exact location of the error...

You can also add the -g option to the linker, this will add some additional classes to your program and will display a mini stack trace if you get an exception. This code will also catch the use of enter+escape and will show the current state/location of each thread in your system. Here are a few notes on using this feature:

If you press "Enter + Escape", you will see the thread state display. At this point you have three options....
1. Press "Enter + Escape" again and the brick will exit.
2. Press Escape and the brick will do a warm start of the menu.
3. Press any other key and the start menu will resume... (the display may
not be correct, I don't attempt to save the contents)...

So what does the thread display mean....

Each line represents a thread in the system. The threads are ordered in
priority order with the highest priority being last (so that if the screen
scrolls you see the high priority threads). The first number is the
threadId, this is followed by a single letter which is the thread state...
R - Thread is runnable
S - Thread is sleeping
D - Thread is dead.
N - Thread is new (not yet started).
I - Thread has been started but not yet run.
E - Thread is waiting to enter a synchronized section.
W - Thread is waiting on an object.
* - Thread is the running thread (not the debug thread).
Following this are up to 3 numbers these represent the top three methods in
a stack trace, the first number is the current method... The display is not
very pretty but I wanted to use the new System.err/out stuff and it is hard to format things/fit them on the LCD display....

Finally you can make use of the leJOS remote console feature to display messages to let you trace what is going on in your code. This lets you hook up a connection via USB or Bluetooth and dump message to your PC. If you redirect the standard java System.err print stream to the stream associated with the console using...

Code: Select all
        System.setErr(new PrintStream(RConsole.openOutputStream()));


Then the above stack dump and Exception display will be directed to the PC console...

Hope this makes some sort of sense

Andy
User avatar
gloomyandy
leJOS Team Member
 
Posts: 3881
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Thank you

Postby calamity » Sun Dec 14, 2008 9:41 pm

Thank you to everyone for your most helpful replies. You were most kind!
calamity
New User
 
Posts: 20
Joined: Sat Nov 29, 2008 11:06 pm


Return to NXJ Hardware

Who is online

Users browsing this forum: No registered users and 0 guests

more stuff