Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Can anyone tell me how to get the Call Stack when a BREW based phone crashes and the reason being Watchdog Reset?

Watch dog resets usually happen when the application does not allow the underlying task to kick the watch dog. For e.g. when you have huge for loops or any other continous loops.. waiting for an event and not allowing any other application or process to run.
Do you have any such things ? You can get the task stack if you are at an OEM level. for brew app.. you can try looking for anything which will block the task..

Watch dog resets usually happen when the application does not allow the underlying task to kick the watch dog. For e.g. when you have huge for loops or any other continous loops.. waiting for an event and not allowing any other application or process to run.
Do you have any such things ? You can get the task stack if you are at an OEM level. for brew app.. you can try looking for anything which will block the task..

Thanks a lot for your reply. But, I have a slightly different impression about dog resets. The phone crashes only when a task fails to report to the Watchdog Task which continuously monitors other tasks and expect each task to report to it after a predefined time-interval after which the Watchdog would kick that task and reset the phone. This is called a Watchdog bite and the non-reporting task is said to be bitten by the Watchdog. But, the non-reporting task may not be the ultimate culprit and could be any other high-priority task who hogged the processor and hence did not allow some low-priority task to report to Watchdog task.
Ok. This was about Watchdog reset. By analyzing the dog_task info and state I can safely assume that it's the "UI" task who failed to report. Now, I want to extract the Call Stack out of it so that I know the exact instruction/set of instructions who is hogging the processor, hence allowing for dog reset. Is there any easy way out?

Thanks a lot for your reply. But, I have a slightly different impression about dog resets. The phone crashes only when a task fails to report to the Watchdog Task which continuously monitors other tasks and expect each task to report to it after a predefined time-interval after which the Watchdog would kick that task and reset the phone. This is called a Watchdog bite and the non-reporting task is said to be bitten by the Watchdog. But, the non-reporting task may not be the ultimate culprit and could be any other high-priority task who hogged the processor and hence did not allow some low-priority task to report to Watchdog task.
Ok. This was about Watchdog reset. By analyzing the dog_task info and state I can safely assume that it's the "UI" task who failed to report. Now, I want to extract the Call Stack out of it so that I know the exact instruction/set of instructions who is hogging the processor, hence allowing for dog reset. Is there any easy way out?

UI task runs Brew usually.
Clearly UI isn't able to hit the watchdog in this case. and since it's within brew, I am not sure if you'd get the proper call stack you are expecting.
You could probably have a look at the ui task tcb and other parameters.

UI task runs Brew usually.
Clearly UI isn't able to hit the watchdog in this case. and since it's within brew, I am not sure if you'd get the proper call stack you are expecting.
You could probably have a look at the ui task tcb and other parameters.

Yes, BREW also runs in the context of UI Task. Currently, I am trying to analyze the signals set for UI and other high-priority tasks than UI. This might give a clue as to who is the culprit task.

Yes, BREW also runs in the context of UI Task. Currently, I am trying to analyze the signals set for UI and other high-priority tasks than UI. This might give a clue as to who is the culprit task.

If you have access, then you can use QXDM, and perform synchronous logging. That would give much better idea.

If you have access, then you can use QXDM, and perform synchronous logging. That would give much better idea.

I have used QXDM too. And it doesn't indicate anything potential in my application.

I have used QXDM too. And it doesn't indicate anything potential in my application.

Try adding debug statement when the watchdog reset happens.. may be to output to a file. it should be able to give you the id of the culprit task.
wrangler_brew wrote:Yes, BREW also runs in the context of UI Task. Currently, I am trying to analyze the signals set for UI and other high-priority tasks than UI. This might give a clue as to who is the culprit task.

Try adding debug statement when the watchdog reset happens.. may be to output to a file. it should be able to give you the id of the culprit task.
wrangler_brew wrote:Yes, BREW also runs in the context of UI Task. Currently, I am trying to analyze the signals set for UI and other high-priority tasks than UI. This might give a clue as to who is the culprit task.

I have a piece of code similar to the following when my application resumes and where the watchdog reset is happening. According to QXDM log, my application does receive the EVT_APP_RESUME event before the phone goes for a toss (Watchdog reset).
case EVT_APP_RESUME:
{
struct Util *psUtil = (Util *) MALLOC (sizeof (Util) );
IAPPLETCTL_Stop (); // With necessary parameters.
OR
ISHELL_CloseApplet (); // With necessary parameters.
->FREEIF (psUtil);

return TRUE;
Do any of you feel this code is right, especially the one indicated by an arrow? Are we allowed to do any further processing after we have requested BREW to close the application such as this one? Can it have any potential side-effects enough to cause this Watchdog reset?

I have a piece of code similar to the following when my application resumes and where the watchdog reset is happening. According to QXDM log, my application does receive the EVT_APP_RESUME event before the phone goes for a toss (Watchdog reset).
case EVT_APP_RESUME:
{
struct Util *psUtil = (Util *) MALLOC (sizeof (Util) );
IAPPLETCTL_Stop (); // With necessary parameters.
OR
ISHELL_CloseApplet (); // With necessary parameters.
->FREEIF (psUtil);

return TRUE;
Do any of you feel this code is right, especially the one indicated by an arrow? Are we allowed to do any further processing after we have requested BREW to close the application such as this one? Can it have any potential side-effects enough to cause this Watchdog reset?

Seems to me like some memory corruption and not watchdog causing the reset.
If you comment out the whole code for app resume, does it work or does it still cause a problem.
If you allow the memory to leak, by removing FREEIF does it work fine ?
or does it still reset ?
You could try these options and check..

Seems to me like some memory corruption and not watchdog causing the reset.
If you comment out the whole code for app resume, does it work or does it still cause a problem.
If you allow the memory to leak, by removing FREEIF does it work fine ?
or does it still reset ?
You could try these options and check..

It seems like the call to ISHELL_CloseApplet ()/IAPPLETCTL_Stop () is causing the problem currently and NOT the FREEIF which I had initially suspected. I can see both these APIs returning SUCCESS on return and I print them through QXDM (the last line of my EVT_APP_RESUME handler), but my application never gets the EVT_APP_STOP notification from BREW thereafter. Can it be a problem on the part of BREW?

It seems like the call to ISHELL_CloseApplet ()/IAPPLETCTL_Stop () is causing the problem currently and NOT the FREEIF which I had initially suspected. I can see both these APIs returning SUCCESS on return and I print them through QXDM (the last line of my EVT_APP_RESUME handler), but my application never gets the EVT_APP_STOP notification from BREW thereafter. Can it be a problem on the part of BREW?

I also see many BPOINT Type 3 (8 of them) in the QXDM logs. Can these corrupted heap nodes cause a Watchdog Reset in my application?

I also see many BPOINT Type 3 (8 of them) in the QXDM logs. Can these corrupted heap nodes cause a Watchdog Reset in my application?

I am not sure if this is exactly a watchdog reset. it could be data abort or any other exception have you checked that up ?
1. For IAppletCtl_stop, you require system privileges ( which i guess your app has!)
do you see any gCL or gSU or similar messages in QXDM logs ? or search for your apps class id to see if you get any logs..
2.Enable brew debug sequence and then enter ###324#, this should launch the debug app, enable memory and event related logging.
-Ash

I am not sure if this is exactly a watchdog reset. it could be data abort or any other exception have you checked that up ?
1. For IAppletCtl_stop, you require system privileges ( which i guess your app has!)
do you see any gCL or gSU or similar messages in QXDM logs ? or search for your apps class id to see if you get any logs..
2.Enable brew debug sequence and then enter ###324#, this should launch the debug app, enable memory and event related logging.
-Ash

I am sure that this is a Watchdog Reset since the phone freezes for a while and then reset. Any other crash would have been almost instantaneous.
I of course see the BREW grinder messages as you have mentioned. But, the last one of them before the crash is like *gRE=0xGHIJKLMN where, 0xGHIJKLMN is the class ID of my application.
I enabled BREW Debug logs, but even that did not help me much in tracing out that issue.

I am sure that this is a Watchdog Reset since the phone freezes for a while and then reset. Any other crash would have been almost instantaneous.
I of course see the BREW grinder messages as you have mentioned. But, the last one of them before the crash is like *gRE=0xGHIJKLMN where, 0xGHIJKLMN is the class ID of my application.
I enabled BREW Debug logs, but even that did not help me much in tracing out that issue.

Do you have a jtag setup ? Does your app get the resume event ?

Do you have a jtag setup ? Does your app get the resume event ?

Yes, I do have a JTAG and my application indeed gets the EVT_APP_RESUME, wherein I call IAPPLETCTL_Stop ()/ISHELL_CloseApplet () which returns SUCCESS to me. While debugging through JTAG, I found that the looping was actually happening inside the BREW AEE before the crash. There were repeated calls to AEE_AddResume (), AEE_CancelResume(), AEE_ResumeCallback () and thereafter the phone Watchdog Resets without my application receiving a EVT_APP_STOP event. It seems like a real problem with the BREW library.

Yes, I do have a JTAG and my application indeed gets the EVT_APP_RESUME, wherein I call IAPPLETCTL_Stop ()/ISHELL_CloseApplet () which returns SUCCESS to me. While debugging through JTAG, I found that the looping was actually happening inside the BREW AEE before the crash. There were repeated calls to AEE_AddResume (), AEE_CancelResume(), AEE_ResumeCallback () and thereafter the phone Watchdog Resets without my application receiving a EVT_APP_STOP event. It seems like a real problem with the BREW library.

Send a brew oem support with the qxdm logs and the snapshot of your jtag trace.
I am supposing you are having oem relation with Qualcomm and not developer...

Send a brew oem support with the qxdm logs and the snapshot of your jtag trace.
I am supposing you are having oem relation with Qualcomm and not developer...

Yes, we are having an OEM relation with Qualcomm. They have replied with the observation that the critical section is being entered (calling AEE_EnterAppContext () ) but not left (no call to AEE_LeaveAppContext () ). This causes the looping in BREW library (variable "uRunningRef" set to "1") and hence the Watchdog Reset. Our BREW OEM Team is trying to figure out why this imbalance is happening.

Yes, we are having an OEM relation with Qualcomm. They have replied with the observation that the critical section is being entered (calling AEE_EnterAppContext () ) but not left (no call to AEE_LeaveAppContext () ). This causes the looping in BREW library (variable "uRunningRef" set to "1") and hence the Watchdog Reset. Our BREW OEM Team is trying to figure out why this imbalance is happening.

wrangler_brew wrote:I also see many BPOINT Type 3 (8 of them) in the QXDM logs. Can these corrupted heap nodes cause a Watchdog Reset in my application?
It means you free the invalid pointer in your application. It won't cause a watchdog reset.

wrangler_brew wrote:I also see many BPOINT Type 3 (8 of them) in the QXDM logs. Can these corrupted heap nodes cause a Watchdog Reset in my application?
It means you free the invalid pointer in your application. It won't cause a watchdog reset.

Yes, my App gets the EVT_APP_RESUME and within that handler I am trying to stop my application.

Yes, my App gets the EVT_APP_RESUME and within that handler I am trying to stop my application.

Is your issue resolved now ? If yes, what was the resolution?

Is your issue resolved now ? If yes, what was the resolution?

We also met the same problem. Is there any solution now? Thanks a lot.

We also met the same problem. Is there any solution now? Thanks a lot.