Thanks Ben.
It was a while ago, but I did debug this and my app was the running app, but the crash
was deep in the OS code - a handle that I didn't have anything to do with.
But, your question is intriguing.... I don't do anything for launch codes I don't
handle, except return a 0 from PilotMain... Come to think of it though... this
problem did creep in when I started handling Tel notifications... See if you see
anything wrong with this:
UInt32 PilotMain (UInt16 cmd, MemPtr cmdPBP, UInt16 /*launchFlags*/)
{
UInt32 error;
UInt16 cardNo;
LocalID appID;
if (cmd == sysAppLaunchCmdNormalLaunch)
{
error = StartApplication ();
if (error)
return (error);
FrmGotoForm (gCurrentView);
EventLoop ();
StopApplication ();
}
// other else if's eleted...
else if (cmd == sysAppLaunchCmdNotify)
{
SysNotifyParamType *notifyP =
(SysNotifyParamType *)NULL;
MobileSvcNotificationType *notifyMTypeP =
(MobileSvcNotificationType*)NULL;
TelNotificationType *notifyTTypeP =
(TelNotificationType *)NULL;
EventType ev;
notifyP = (SysNotifyParamType *)( cmdPBP );
switch ( notifyP->notifyType )
{
case kMobileSvcNotification:
notifyMTypeP = (MobileSvcNotificationType *)(
notifyP->notifyDetailsP );
switch ( notifyMTypeP->notificationId )
{
case kMobileSvcPowerProgressStop:
ev.eType = phoneDoneOn;
EvtAddEventToQueue(&ev);
break;
case kMobileSvcPowerOffComplete:
ev.eType = phoneDoneOff;
EvtAddEventToQueue(&ev);
break;
case kMobileSvcPowerOffFailed:
case kMobileSvcPowerOnFailed:
ev.eType = phoneDoneFailed;
EvtAddEventToQueue(&ev);
break;
default:
break;
}
break;
default:
break;
}
}
return (0);
}
I don't register for time change events, so I wouldn't expect to get them...
I'm going to debug it again so I can give you better information about the stack, etc.
This was a problem we were going to live with since it seemed to happen only in a
testing/debugging scenario, but now that we've seen it in real life scenarios, we are
going to have to deal with it...
Thanks,
Kevin
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ben
Combee
Sent: Tuesday, August 17, 2004 4:03 PM
To: Palm Developer Forum
Subject: Re: Chunk Overlocked Fatal Alert when using TimSetSeconds
At 05:21 PM 8/17/2004, you wrote:
>Wondering if anyone else has experienced this...
>
>We have a testing mode for our application that lets testers
>"fast-forward" time to just before the next alarm is supposed to
>fire. When they activate this feature, the code just gets the time for
>the next alarm and then uses TimSetSeconds to set the device clock to 1
>minute before that alarm is to fire. This works fine.
>
>However, somewhere around the 15th or 16th TimSetSeconds, the OS crashes
>with a fatal alert Chunk Overlocked.
>
>I do not register for the Time changed notification. (Should I?).
The bigger question is "do you do anything in the logic for ignored launch
codes that could leave a handle locked?"
If you're on a 68K device, you should be able to debug this, get a stack
crawl, and see what application was active when this happens.
-- Ben Combee, DTS technical lead, PalmSource, Inc.
"Combee on Palm OS" weblog: http://palmos.combee.net/
Palm OS Dev Fourm Archives: http://news.palmos.com/read/all_forums/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
------------------------------------------
The information in this transmittal and any attachments are confidential and intended
only for the recipient(s) listed above. You are hereby notified that any unauthorized
distribution or copying of this transmittal or its attachments is prohibited. If you
have received this transmittal in error, please notify invivodata immediately at (831)
438-9550.
------------------------------------------
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
