Crashes in phone app

[pruss]

I've recently been getting chunk overlocked crashes in the phone app on my 700. I couldn't figure out what was causing it, so I just wrote a hack to disable the resets (the chunk overlocking probably is still happening, and maybe doing something bad to my system, but it may be better than a reset in the middle of writing an email). Anybody else having this?

[Greek]

I had them on my 650. The crashes happened when the Phone app was idle, not during calls fortunately. Happily, now that I have the Centro, crashes have gone. :)

Regards,

[JerryG]

Alex - any pattern to the occurrences? On a call, just sitting with the dial-pad / some favorites showing? Or just "random"?

-JerryG

[danceman]

try moving the file PhoneFavorites2DB to a card. Palm will make a new file. Sometimes PhoneFavorites may get corrupted. If things don't get better just move it make. This file has all the favorites of the phone app that Butler and Takephone and other apps use.

Takephone has a Defrag Favorite feature but I don't know if this fixes anything or just cleans out the empty slots.

[pruss]

Alex - any pattern to the occurrences? On a call, just sitting with the dial-pad / some favorites showing? Or just "random"?

-JerryG

It would reset just sitting there, or in the middle of my writing an email (with its flagged as happening in the Phone app). I haven't had one since I installed my little hack, but the hack just masks the problem. I guess I could set the hack to log overlock attempts, but I don't think I want to go to all that trouble.

[technical1]

Alex,

How's your usual level of dbcache & do you have any (new) apps that might have settings that would conflict w/existing apps, like some in Butler & Phone both dealing w/the green button on the Treos?

[dmitrygr]

it happens at times because of a hardware bug. i've known palm to replace devices that do that after a hard reset, so HR and see if it still happens, if so, get it replaced

[pruss]

it happens at times because of a hardware bug. i've known palm to replace devices that do that after a hard reset, so HR and see if it still happens, if so, get it replaced

Would Palm replace it long after the warranty has expired?

[dmitrygr]

no idea, sorry. but first try a hard reset and see if it still crashes

[technical1]

Alex,

Doesn't the err msg itself reflect that it is memory that has been requested/locked by an app that another app has already requested/locked?

I just got CallRec & it has a feature to manipulate the LED when working, which is the same thing that Butler does when dealing w/it's Alarms & Attention grabber.

Since both wanted the same resource, I was sure to choose diff color & was prepared to choose diff actions i.e. light up green vs. blink green if the diff color settings for ea. app didn't help... Also noticed some diff. 'unhealthy' behavior in my Centro when I chose Orange for the LED, so I went back to good 'ole standy red & green... too bad. Orange fits in my theme...color choices... but I digress.

I would say, imho, as a user who has experimented w/lots of betas, that it seems to be an issue of apps w/similar functionality whose implementations conflict....

[JerryG]

Hardware bug? Hmm.

I'm totally unfamiliar with the CPU architecture of the 700, or of the OS, but does Palm OS set aside a particular hardware register, exclusively for the lock counts? That might be work-around-able... I'd expect behavior like this if a transistor on the IC is flaking out, intermittently...

Anyway, I wouldn't believe it's always the Phone apps fault. I've had Crash Pro report crashes caused by programs that weren't even running at the time. Same thing with the built-in reporting.

The development of the error handling routines in the Palm OS definitely did NOT get a substantial amount of time and money, from Palm. Got an error? Reboot! Feh!

-JerryG

[pruss]

Doesn't the err msg itself reflect that it is memory that has been requested/locked by an app that another app has already requested/locked?

Typically the message reflects the fact that a developer has failed to match every MemHandleLock() with a MemHandleUnlock(), so that each time the piece of code runs, memory gets locked an extra time. After this operation happens 15 times, thereby exceeding the maximum number of locks on a handle, the device crashes. My workaround basically has it ignore further locks after the 14th. The memory does stay locked, which isn't good in regard to fragmentation and deletion, but it's better than a crash.

By the way, the lock count is not in a hardware register. It is in the four-bit lockCount field of the memory chunk structure.