FAQ-1254 MEM-01: How can I prove that a LowMem failure is caused by the underlying OS and not my application?


FAQ-1254 MEM-01: How can I prove that a LowMem failure is caused by the underlying OS and not my application?

» Symbian OS » Developer Knowledgebase » FAQ-1254

Classification:	General	Category:	Symbian Signed
Created:	04/01/2005	Modified:	04/15/2005
Number:	FAQ-1254
Platform:	Not Applicable

Question:
How can I use LowMem test output logs to debug failures?

Answer:
For most applications, the LowMem test tool's default initial free heap value is set high to account for system issues; so that any errors reported can be attributed to the application. However, some applications (for example, document-based applications) can show system related memory issues even when using the minimum free memory setting. This FAQ provides a method for proving that these are System related rather than application related. Such issues can be waived via the waiver process, as explained in the LowMem User Guide. Debugging information should accompany the waiver request to pass the MEM-01 test.

Because the system base UI code houses most of the inititialization code for the application, most system issues appear when the base UI method CEikAppUi::BaseConstructL() is executed. Equally, other system code can also fault when the application UI code is run e.g. when creating views, populating a list etc. The below strategy can be applied to any piece of the application code (which is executed during construction) to debug a failure

Focusing on CEikAppUi::BaseConstructL() issues, first put a User::Panic() before this method. If the panic shows up in the LowMem logs as the cause of the thread dying, then the source of the system Panic must be after the point where your debug panic has been inserted. The LowMem log below shows this:

...
16384,BeforeBaseConstr,1 17408,BeforeBaseConstr,1
18432,BeforeBaseConstr,1 19456,BeforeBaseConstr,1
20480,BeforeBaseConstr,1 21504,BeforeBaseConstr,1
...

You then place the panic immediately following the call to the AppUI BaseConstructL() - removing your first panic. If a system panic occurs, then BaseConstructL must have been the source of hte panic. The log below shows that the system error occuring until there are 3500K bytes of free memory, after which your "User" debug panic occurs. Therefore for this application, 3500K is a reasonable minimum default test value. Note that test houses will not use this new value to test your application. The test will undergo using the default LowMem settings and the issue(s) should be waived after the test house testing has been conducted.

Requested free bytes,Exit category,Exit reason
20480,Kill,-4 21504,Kill,-4 22528,Kill,-4 23552,Kill,-4 24576,Kill,-4
25600,Kill,-4 26624,Kill,-4 27648,Kill,-4 28672,Kill,-4 29696,Kill,-4
30720,KERN-EXEC,3 31744,KERN-EXEC,3 32768,KERN-EXEC,3 33792,KERN-EXEC,3
34816,Kill,-4 35840,AfterBaseConstru,1 368;64,AfterBaseConstru,1
37888,AfterBaseConstru,1 38912,AfterBaseConstru,1
...

You should provide the above debug information in your application waiver request.