Checking stack blowing wih Palm OS Debugger

Go to the debug tab in POD (Palm OS Debugger)
Type prot nub kinfLook for your thread and get the top of the stack pointer (not the current stack ptr)
Type prot nub dbreak 0x.... (the address of the top of the stack)
Then it will break if you ever write to the top of the stack.

By the way, I found Palm Debugger and Palm OS Debugger would conflict while conncting to device, only one should work at one time.

Unstable issue in Palm ARM multithreading program

Recently we got our ARM multithreading application running unstable in the device. After we learned from Palm that how to save the enviroment from the crashed device by using serial cable and Palm ARM OS debugger(very useful way!), we found the device crashed could be anywhere, very weird. Then after Palm review our code and point it out that we didn't initial the thread correctly, we fixed the unstable issue.

This is the sample thread callback function.

static void
TaskMailboxThread(void * paramP)
{
Err err = errNone;
SysAppInfoType* appInfoP;
SysAppInfoType* dummyP;
KernelID taskid;
KALTaskInfoType info;
EmulStateRef emulStateRef = 0;
UInt32 mailboxMessage = 0;

//HsExtTraceFunction (gTraceContextP, "TaskMailboxProcCallback", NULL);

KALTaskGetCurrentID(&taskid);
KALTaskGetInfo(taskid, &info);


// Fix AppInfo, since SysTaskCreate just copies it from the creating task
appInfoP = SysGetAppInfo(&dummyP, &dummyP);
MemSet(appInfoP, sizeof(SysAppInfoType), 0);

// Put in pre-opened system databases into the DmAccess List
// appInfoP->dmAccessP = ((SysAppInfoPtr)GSysAppInfoP)->dmAccessP; //DOLATER: really need this?
appInfoP->memOwnerID = 0; // Assume that we're only creating threads for the system

// Set the stack fields
appInfoP->stackP = (UInt8 *) info.stack;
appInfoP->stackEndP = appInfoP->stackP + info.stackSize - 1;


if(PceAllocEmulState(0, &emulStateRef) == errNone)
{
PceSetCurrAppEmulState(emulStateRef);
}

……

}

Unstable issue in Palm 68k program with sms handler

Recently I found our agent which runs on Palm Camino device sometimes got crash. The crash mix up with Progress bar, TCP connection and Configuration modules.

Here is release notes relates to the issue
1. This issue is as same as the issue in last 3.6.6 build, still not exactly knows why; Base on the behavior and fix, I think it relates to common code stack usage overflow. The fix is just restructuring the code to make it consumes less stack memory, no code logic change.

2. We don’t exactly know what cause the 6534 issue, but we found if we tried to reduce memory usage, the stability issue would be improved. In SC3.6.8 build, SmartCare definitely would crash in TCP configuration, after we restructured the code, this is not definitely happen, but we still can see at some point SmartCare would crash, so for now we decided to remove the progress bar and tried to consume less memory to make SmartCare more stable. So far I didn’t get any crash report on SC3.6.9 build.

Finally I think it may relates to SMS handing architecture in our agent. Before, we register SMS handler to the system and when SMS request comes in, system will wake agent up, and agent will work base on the request. As features and functions increase in the code, the memory and time consuming would be a problem as a SMS event handler which I think it is the major reason of unstable issue. So I changed the this part of the agent, use two phase wake up process, in the SMS evnet handler, I just scan if the sms is our own request, if it is, then copy it and use SysNotifyBroadcastDeferred to pass the SMS to the agent again. Now so far so good, the unstable issue seems fixed.