#18 Calc cannot store state on Nokia 6300

[Hanspeter Schmid]

On my Nokia 6300, calc does not save its state when the hangup button is pressed.

The second possibility, "mode/sys/exit", gives a "program error" and nothing is saved either.

[Hanspeter Schmid]

Found two more things:

1. The error is a "Null Pointer java/lang/NullPointer Exception"

2. This error only comes the first time that mode/sys/exit is used after installing or after a reset. From the second time onwards, calc works fine.

[Hanspeter Schmid]

Found another thing: my point 2. in my previous comment is incorrect. The error ALWAYS appears if no program is defined. If a program is defined, it won't appear.

(Reason for my incorrect analysis: previously I thought it would be the first time because in order to create a state to save, I created a program.)

[Roar Lauritzsen]

This is the second bug where someone gets a NullPointerException on exit, so it might be a general problem, not specific to Nokia 6300. However, I haven't experienced the bug, and I don't se anything suspicious about the code used when saving programs.

It would be interesting if you performed two additional experiments:
1) Using mode/sys/reset, you can reset to a "clean" state. Do you get a NullPointerException from "mode/sys/exit" in a clean state? If not, what is the minimum number of steps necessary to see the exception?
2) Once you have found the minimum number of steps to reproduce the bug, try it on a different phone.

[Hanspeter Schmid]

Hi Roar,

my experiment protocol:

- start
- mode/sys/reset OK >> program closes
- start >> setup process starts, stack empty
- 42 enter mode/sys/exit >> null pointer exception
- start >> the number 42 is on the stack
- mode/sys/exit >> null pointer exception
- start >> the number 42 is still on the stack
- create a function "f3" that does nothing
- moode/sys/exit >> program closes cleanly
- start >> number 42 on the stack
- mode/prog/run "f3" >> runs
- mode/sys/exit >> program closes cleanly
- start >> 42 on stack
- mode/prog/more/clear "f3" mode/sys/exit >> program closes cleanly
- start >> 42 on stack
- recreate "f3" mode/sys/exit >> program closes cleanly
- open >> 42 on stack

And now an interesting part:

- hangup key OK >> program closes cleanly
- start >> 42 on stack, "f3" still there
- mode/sys/exit >> null pointer exception
- open >> stack empty, function "f3" disappeared, but setup screens don't come
- mode/sys/exit >> null pointer exception
- open >> 42 on stack function "f3" here again (???)

and from here on EVERY mode/sys/exit gives a null pointer exception. So I reset again, start again, same thing happens.

I don't have access to another phone, my wife also has the 6300. But if you wish to send me a version that writes out debugging messages such that I can help you locate the bug, I'm ready to do this.

[Hanspeter Schmid]

Hi Roar,

had a bit of time & looked at your source. I'm not really a Java programmer (my poison of choice is Perl), so please don't laugh if I got this wrong. But I think that mode/sys/exit always calls

public void trim() {
short [] prog2 = new short[progSize];
System.arraycopy(prog[currentProg],0,prog2,0,progSize);
prog[currentProg] = prog2;
}

along the way even if no program is defined, and if no program has ever been defined, then progSize is undefined, and I think this routine then fails with a NullPointerException. I think you should catch this case somewhere.

Am I right or should I just stop trying to understand Java source?

[Roar Lauritzsen]

Your analysis was not correct, although it got me analyzing myself. I found one problem that could explain things, so I will include a fix for that in the next version, and hope this fixes things.

When it comes to java, there is no such thing as an undefined value. Specifically, all class fields are initialized to 0 if nothing else is specified.