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

Developer

Forums

Once my game is playing, it handles memory allocation failure fairly gracefully, but in some parts of my program, a memory allocation failure simply crashes the game. Do I need to go through every place where an allocation occurs and ensure that it can fail gracefully? Or is it enough that I've put some effort towards it?

Basically, do I have to be 100% bulletproof? Can any game really be 100% bulletproof?

If an allocation failure causes the device to lock up or reset (e.g. dereferencing a NULL pointer) you will likely fail testing. Yes, you have to handle every potential failure.

If an allocation failure causes the device to lock up or reset (e.g. dereferencing a NULL pointer) you will likely fail testing. Yes, you have to handle every potential failure.

How do they test for memory failures? Is it standard usage memory failures? Or do they put it through bizarre memory fluctuations and memory corruption? Also, where in the NSTL guidelines does it describe how they test for memory failures? I see The Grinder, but thats it. The word memory appears only twice in the whole document.
My application checks to make sure there is enough RAM when it starts, and since BREW is not much of a multitasking environment, and my project is a port from Java, I have done my best to ensure that it either runs in a sane environment, or quits if it detects too much rockiness. As it appears under standard usage on fully loaded phones right now, the game is bulletproof. I just want to know if they use bazookas.

How do they test for memory failures? Is it standard usage memory failures? Or do they put it through bizarre memory fluctuations and memory corruption? Also, where in the NSTL guidelines does it describe how they test for memory failures? I see The Grinder, but thats it. The word memory appears only twice in the whole document.
My application checks to make sure there is enough RAM when it starts, and since BREW is not much of a multitasking environment, and my project is a port from Java, I have done my best to ensure that it either runs in a sane environment, or quits if it detects too much rockiness. As it appears under standard usage on fully loaded phones right now, the game is bulletproof. I just want to know if they use bazookas.

NSTL will force memory allocation failures to occur. Just go through your code and ensure that each allocation is checked for a NULL pointer return value.
If the allocation fails, present the user with an error message for a few seconds then exit. I don't know what else I can tell you. Just write good code and you'll be fine.
There's no "inside scoop" on how NSTL tests. Use the shaker to test low memory on the device and reduce the heap size using the device configurator to test for low memory conditions in the emulator. Also, in the Emulator, press "###6" to turn on "DEBUG NULL". This will cause the grinder to fail every 100th or so allocation so that you can see how your app. reacts. If you get any NULL pointer dereferences, that indicates a problem that needs to be fixed.

NSTL will force memory allocation failures to occur. Just go through your code and ensure that each allocation is checked for a NULL pointer return value.
If the allocation fails, present the user with an error message for a few seconds then exit. I don't know what else I can tell you. Just write good code and you'll be fine.
There's no "inside scoop" on how NSTL tests. Use the shaker to test low memory on the device and reduce the heap size using the device configurator to test for low memory conditions in the emulator. Also, in the Emulator, press "###6" to turn on "DEBUG NULL". This will cause the grinder to fail every 100th or so allocation so that you can see how your app. reacts. If you get any NULL pointer dereferences, that indicates a problem that needs to be fixed.

Hi Murray Booner,
Any ideas as to how they will check if a memory alloc failure occured in BREW code or in the app code?
I am having some IIMAGE_Draw functions which are causing heap alloc failures. And since this function does not return an int is there is no way to trap this failure?
The subsequent behvaiour is that some images on my app does not appear.
This does not happen in the case of the phone having its regular memory but when I reduce the available memory using device configurator.
Any ideas if this will be a problem for TBT?
Thanks

Hi Murray Booner,
Any ideas as to how they will check if a memory alloc failure occured in BREW code or in the app code?
I am having some IIMAGE_Draw functions which are causing heap alloc failures. And since this function does not return an int is there is no way to trap this failure?
The subsequent behvaiour is that some images on my app does not appear.
This does not happen in the case of the phone having its regular memory but when I reduce the available memory using device configurator.
Any ideas if this will be a problem for TBT?
Thanks

I had the same thing occur lots of times when I tested apps with the grinder and DEBUG NULL enabled (causes alloc's to fail).
There were MANY times that an alloc failure would occur that my code couldn't detect because there was no return value to check.
I've had two app.'s pass TBT and both of them experienced the exact same problems you are describing during my own testing.
So, from my experience, the answer to your question is that such undetectable failures will not lead your app to fail TBT. After all, there's really nothing you can do about them.

I had the same thing occur lots of times when I tested apps with the grinder and DEBUG NULL enabled (causes alloc's to fail).
There were MANY times that an alloc failure would occur that my code couldn't detect because there was no return value to check.
I've had two app.'s pass TBT and both of them experienced the exact same problems you are describing during my own testing.
So, from my experience, the answer to your question is that such undetectable failures will not lead your app to fail TBT. After all, there's really nothing you can do about them.

Thats good to know.
But the only concern I have is that i use bitmaps to "show" my soft keys instead of using the SoftKeyMenu datatype of BREW. it just helps to show funky stuff lot easily. Now there is a possibility in low memory tests that the "soft key" menu might not come up. I hope TBT does not treat it as a failure.
Thanks

Thats good to know.
But the only concern I have is that i use bitmaps to "show" my soft keys instead of using the SoftKeyMenu datatype of BREW. it just helps to show funky stuff lot easily. Now there is a possibility in low memory tests that the "soft key" menu might not come up. I hope TBT does not treat it as a failure.
Thanks

Do I have to check a lot of trivial things like "IMENUCTL_AddItem()".
Here is the story, I tried to set the phone's memory to a very low level using Grinder, my splash image can not be loaded, so the application goes directly to Main Menu. I guess that all the "IMENUCTL_AddItem()" failed so my main menu only shows the title but all the menu items are missing.
Also I noticed that under very-low momory condition, almost all the apps (including commercial one) can not be started at all. (Click the icon and nothing happen). It looks like MALLOC failure in HandleEvent and InitAppData is handled by BREW iteself. Do I have to check those MALLOCs?
Thanks for your reply.

Do I have to check a lot of trivial things like "IMENUCTL_AddItem()".
Here is the story, I tried to set the phone's memory to a very low level using Grinder, my splash image can not be loaded, so the application goes directly to Main Menu. I guess that all the "IMENUCTL_AddItem()" failed so my main menu only shows the title but all the menu items are missing.
Also I noticed that under very-low momory condition, almost all the apps (including commercial one) can not be started at all. (Click the icon and nothing happen). It looks like MALLOC failure in HandleEvent and InitAppData is handled by BREW iteself. Do I have to check those MALLOCs?
Thanks for your reply.

I have not been able to come up with a number for the size of memory to make the app fail at IMENUCTL_AddItem, but i do check for failures at all places where MALLOC fails and also I check for the return values of all BREW functions which return an error int.
It is left to the developer at that point, how they want to handle the error condition.
My app is still in TBT, so I will be able to tell you more on how NSTL treats "my handling" of those condition, once I get the result back from them.
Thanks

I have not been able to come up with a number for the size of memory to make the app fail at IMENUCTL_AddItem, but i do check for failures at all places where MALLOC fails and also I check for the return values of all BREW functions which return an error int.
It is left to the developer at that point, how they want to handle the error condition.
My app is still in TBT, so I will be able to tell you more on how NSTL treats "my handling" of those condition, once I get the result back from them.
Thanks

By not checking ALL function return values and ALL MALLOC()'s, you increase your chances of failing testing. In my opinion, if an app. doesn't check these things, it SHOULD fail.
If the failure of your IMENUCTL_AddItem()'s renders your main menu unusable, then checking this function's return value must not be "trivial".
Quote:It looks like MALLOC failure in HandleEvent and InitAppData is handled by BREW iteself.
Not true. If an allocation in initData() fails, it should return FALSE and, in turn, the developer must see to it that AEEClsCreateInstance() fails, preventing the app. from being started.
Similarly, if an allocation fails in EVT_APP_START, FALSE should be returned to the AEE, assuming the developer can do nothing to make the required memory available. This will cause freeAppData() to be called and the AEE will display a message to the user indicating that the app. could not be started.
If a memory allocation fails ANYWHERE in your app., this is clearly an indication that your app. should do something (exit) before instability renders your app. or, worse, the phone, unusable.

By not checking ALL function return values and ALL MALLOC()'s, you increase your chances of failing testing. In my opinion, if an app. doesn't check these things, it SHOULD fail.
If the failure of your IMENUCTL_AddItem()'s renders your main menu unusable, then checking this function's return value must not be "trivial".
Quote:It looks like MALLOC failure in HandleEvent and InitAppData is handled by BREW iteself.
Not true. If an allocation in initData() fails, it should return FALSE and, in turn, the developer must see to it that AEEClsCreateInstance() fails, preventing the app. from being started.
Similarly, if an allocation fails in EVT_APP_START, FALSE should be returned to the AEE, assuming the developer can do nothing to make the required memory available. This will cause freeAppData() to be called and the AEE will display a message to the user indicating that the app. could not be started.
If a memory allocation fails ANYWHERE in your app., this is clearly an indication that your app. should do something (exit) before instability renders your app. or, worse, the phone, unusable.

Thanks a lot.
I checked the two example apps: ExpenseTracker and RoadWarrior. I believe that QualComm claims that one of those two passed TBT (I fogot which one). Neither of them check IMENUCTL_AddItem(). I followed almost the same codes to do splash screen and main menu. On very-low-level momery case, the main menu can not be shown correctly.
I am confused. :confused:

Thanks a lot.
I checked the two example apps: ExpenseTracker and RoadWarrior. I believe that QualComm claims that one of those two passed TBT (I fogot which one). Neither of them check IMENUCTL_AddItem(). I followed almost the same codes to do splash screen and main menu. On very-low-level momery case, the main menu can not be shown correctly.
I am confused. :confused:

Quote:Originally posted by brewme
Thanks a lot.
I checked the two example apps: ExpenseTracker and RoadWarrior. I believe that QualComm claims that one of those two passed TBT (I fogot which one). Neither of them check IMENUCTL_AddItem(). I followed almost the same codes to do splash screen and main menu. On very-low-level momery case, the main menu can not be shown correctly.
I am confused. :confused:
How are you loading the menu items? For me, I load all of my menu strings from the bar file. If the ISHELL_LoadResString fails then I exit the app (as I always do if an allocation or resource retrieval fails).

Quote:Originally posted by brewme
Thanks a lot.
I checked the two example apps: ExpenseTracker and RoadWarrior. I believe that QualComm claims that one of those two passed TBT (I fogot which one). Neither of them check IMENUCTL_AddItem(). I followed almost the same codes to do splash screen and main menu. On very-low-level momery case, the main menu can not be shown correctly.
I am confused. :confused:
How are you loading the menu items? For me, I load all of my menu strings from the bar file. If the ISHELL_LoadResString fails then I exit the app (as I always do if an allocation or resource retrieval fails).

RoadWarrior might not be the best example to learn from -- there isn't a single call to MALLOC in the entire program.
My opinions:
1. You MUST check every dynamic memory allocation. If the pointer is NULL, do something so that it is impossible for a NULL pointer to be dereferenced, since this will cause a device reset (I exit the app. since one failure indicates that there will be more if the app. continues to run). If your app. causes a device reset when they are testing it under low memory conditions, it is my opinion that your app. will fail TBT.
2. You SHOULD check the return value of every API function call that provides one. To me, not doing so is just plain lazy. Note that IMENUCTL_AddItemEx() can return TRUE even if the internal memory allocation that provides space for the item's image (if you've included an image for the item) fails. This will be evidenced by the image failing to show up in the menu item. There is nothing you can do about this, since the function's return value fails to capture this internal failure. The user can still use the item, even if the image doesn't show. Thus, if there's a text label that appears in the item, this failure may not be fatal.
To me, if _AddItem() fails, this indicates a problem with the menu that may affect the user's ability to to work with the app.. Imagine it's a crucial item that provides access to some important part of your app.'s functionality. If this item fails to appear in the menu, shouldn't your app. detect this and take some action?
I have had two applications pass TBT on the first go and I believe that my adherence to the above policy has something to do with it. That said, there might be those out there (who I've now pissed off by calling them lazy) who don't check a single return value and have had 10 app.'s pass TBT on the first try.
The choice is yours.

RoadWarrior might not be the best example to learn from -- there isn't a single call to MALLOC in the entire program.
My opinions:
1. You MUST check every dynamic memory allocation. If the pointer is NULL, do something so that it is impossible for a NULL pointer to be dereferenced, since this will cause a device reset (I exit the app. since one failure indicates that there will be more if the app. continues to run). If your app. causes a device reset when they are testing it under low memory conditions, it is my opinion that your app. will fail TBT.
2. You SHOULD check the return value of every API function call that provides one. To me, not doing so is just plain lazy. Note that IMENUCTL_AddItemEx() can return TRUE even if the internal memory allocation that provides space for the item's image (if you've included an image for the item) fails. This will be evidenced by the image failing to show up in the menu item. There is nothing you can do about this, since the function's return value fails to capture this internal failure. The user can still use the item, even if the image doesn't show. Thus, if there's a text label that appears in the item, this failure may not be fatal.
To me, if _AddItem() fails, this indicates a problem with the menu that may affect the user's ability to to work with the app.. Imagine it's a crucial item that provides access to some important part of your app.'s functionality. If this item fails to appear in the menu, shouldn't your app. detect this and take some action?
I have had two applications pass TBT on the first go and I believe that my adherence to the above policy has something to do with it. That said, there might be those out there (who I've now pissed off by calling them lazy) who don't check a single return value and have had 10 app.'s pass TBT on the first try.
The choice is yours.

Thanks. I agree with you. Your advice is very helpful.

Thanks. I agree with you. Your advice is very helpful.

I have found it helpful to write my own MALLOC wrapper that randomly fails. This allows you to to even better testing than the DEBUG NULL.
Its also very useful to change the amount of memory your emulated device has in the Device Configurator.
-Aaron

I have found it helpful to write my own MALLOC wrapper that randomly fails. This allows you to to even better testing than the DEBUG NULL.
Its also very useful to change the amount of memory your emulated device has in the Device Configurator.
-Aaron