Unusual soft reset while using flashcards on my Treo 650

[lmcjipo]

Hi Mike,

While using my existing PlecoDict on my Treo 650, I encountered my first soft reset with PlecoDict.

When I press go to my phone application and "call" #*377, I get the following System Error log message: A reset was caused on m-d-yy at hh:mm while running "PlecoDict": MemoryMgr.c, Line:3843, Non-word-aligned handle

Does this error mean anything to you?


Thanks.

 

[mikelove]

Doesn't mean much, no - most likely some sort of bug, but it's almost impossible to pinpoint where exactly it is. What were you doing at the time of the crash?

 

[lmcjipo]

Hi Mike,

I wasn't doing anything special with my Treo 650.

In fact, while in my flashcard session I received a phone call (on a landline phone and not my Treo 650). I placed my Treo 650 on my desk while I answered the phone call. The flashcard session was in the foreground. After about 10 minutes or so (not sure of the exact time), my Treo 650 did a soft reset while I was still talking on the phone. When I heard the reset sound, I turned and looked at my Treo 650 and saw it reset.

I haven't written any programs in a long time and Palm programming might be different from the programming languages that I used to know but when I saw the error that I reported, I thought that maybe the line 3843 would indicate the source of the error (much like some programming languages' syntax errors reference the offending line/code).

Oh well, it hasn't happened since that random occurance so if the number doesn't mean anything, it isn't a big deal.


Thanks,


Jim

 

[mikelove]

Unfortunately, the line number doesn't say where the problem is in our code, it says where the problem is in Palm's; the Palm OS has kind of an antiquated design, and rather than returning an error to a program and allowing it to be handled gracefully it simply dies and spits out a vague error message.

Strange that it would reset while you weren't doing anything... did the phone turn off automatically during that time? Were you running any other applications in the background (MP3 players, etc)?

 

[Jim]

When the phone resets while it is just sitting there it is very likely that a phone call or SMS came in and the phone reset before it had a chance to ring. Check #*377 again and see if the error is different than before which it may or may not be. It is also possible that some other software running in the background caused the reset. The more that you have running in the background the more likely that an incoming call or SMS will cause a reset and some apps are more inclined than others to cause problems.

 

[lmcjipo]

Unfortunately, the line number doesn't say where the problem is in our code, it says where the problem is in Palm's; the Palm OS has kind of an antiquated design, and rather than returning an error to a program and allowing it to be handled gracefully it simply dies and spits out a vague error message.

That's very interesting. How do Palm programmers debug their programs with such a system? When the line number doesn't mean anything, debugging non-logical errors seems impossible.

Strange that it would reset while you weren't doing anything... did the phone turn off automatically during that time? Were you running any other applications in the background (MP3 players, etc)?

No, I exited the program that I normally have running in the background (a chatting program). Generally, I always exit this chatting program because it is known to cause random soft resets. When I launch PlecoDict, I normally try to exit all my applications.

It isn't really a big deal. So far, it hasn't happened again.

 

[lmcjipo]

When the phone resets while it is just sitting there it is very likely that a phone call or SMS came in and the phone reset before it had a chance to ring. Check #*377 again and see if the error is different than before which it may or may not be. It is also possible that some other software running in the background caused the reset. The more that you have running in the background the more likely that an incoming call or SMS will cause a reset and some apps are more inclined than others to cause problems.

I doubt that it was someone calling me (before my Treo actually had a chance to ring) which caused my Treo 650 to reset. The reason for this is that no one has my Treo 650's phone number. Since no one has my cellphone number, calls that I normally get on my Treo 650 are routed/forwarded from another phone number (which logs all incoming calls that are routed/forwarded to my Treo 650). The log that I have indicates that no calls were forwarded/routed to my Treo 650 during that time. An SMS is also unlikely since I told my provider that I don't want to receive SMS. The reason I told them to do this is because my provider charges for all SMS messages received so when/if I get spam SMS messages, I wind up paying for them. At least with telemarketing calls, I can not pick up the phone and I don't have to pay. With SMS messages, I pay regardless of the type of message received.

When I dialed #*377, it just mentioned "PlecoDict" and the line number that I mentioned above. I did it twice after a few seconds since I was transcribing the error message onto this forum and the message disappeared from my screen and I didn't get enough time to transcribe it. Both times, it was the same message.

As I mentioned, it isn't really a big deal since it has only happened once. I only thought that the line number would mean something and since it doesn't really mean much, it isn't a big deal.

 

[mikelove]

How do Palm programmers debug their programs with such a system? When the line number doesn't mean anything, debugging non-logical errors seems impossible.

It's pretty darn close . The line number isn't completely meaningless, it usually does tell you which system call the problem occurred in (or at least it does if you have access to the Palm OS source code, which we do), but beyond that you pretty much have to come up with your own methods for finding errors. In a case like this one, since it's an easy-to-detect error we'd probably just find each instance of the problem function and put a one-line check before it:

assert (((int) handle) % 4 == 0);

But that could be a bit of a performance drag if we left it in the release version, so we'd only put that sort of check in a beta.

Anyway, glad to hear that it's not a big deal, but if the problem keeps happening let me know and we can look into it more seriously.