Symbian Signed - Low Mem test

[rave_symbian]

We have tried testing our Series 60 application with the Symbian Signed Low Mem Tool developed by NewLC.

I quote the following from the NewLC forum since our problem is identical -

Here is the final result: the application has failed to boot in 73% of the test (which is really too much according to Symbian Signed criteria).

Tried the EPOCHEAPSIZE but doesn’t work.

More importantly, what kinds of exception handling are needed to make an application "really" meeting the 10% target? I mean, what the Symbian Signed guys really want developers to do? It seems that an application generated by the S60 SDK appwizard still fails more than 50%.

What kind of exception handling are we supposed to put up in the Application/Document/AppUI code?

Please help.

[rave_symbian]

Any hints on this?
Certification says that developer should handle low memory condition at startup, but no ones telling what exactly to do / expected.

Anyone any ideas. I tried searching for it on the net, but with no results.

Yucca??

Regards,
rave_symbian

[laa-laa]

Did you read the criteria document available from www.symbiansigned.com? I think it is quite clear:

Application start-up during low memory situations. If the application does not start due to lack of memory it indicates to the user that there is not enough memory.

Application usage when the storage memory is low: The application will not fill the storage space of the device. Indicates there is not enough storage space available

Lauri

[rave_symbian]

We have already referred to the Symbian Signed Docs and it doesn't specify what a developer has to incorporate in his application to do so.
It specifies what is required, but we require info on how that can be acheived.

[laa-laa]

Symbian Signed criteria are the what, not the how. Anyway, the how part needs some assumptions about your code. I'm assuming it's a normal event-handling GUI application.

Start-up requirements can be fulfilled by using the cleanup stack, traps and leaves normally. For example, if you let a KErrNoMemory leave propagate to application architecture trap harness during application construction, a "not enough memory" dialog box will automatically be shown and the application is closed. There's no problem if your application cannot be started. But then there is a problem if the user does not know why.

The same normal exception handling mechanism is a key component in fulfilling runtime requirements as well but this time a leave generally does not close the application (goes to active scheduler's RunError) so you should design your app to handle OOM situations gracefully, and test it as well (for example, using the __UHEAP_SETFAIL macro and its friends). And if you're writing data to the file system, you must make sure that you don't take up all disk space and your application works even if there is no disk space left.

Lauri

[rave_symbian]

I agree with your statements on how to take care of the Low Mem situations with Traps & Leaves.
Lets consider this practical situation of a Series 60 AppWizard generated application. That fails the Low-mem test too.
Can you tell me what Traps & Leaves should I add to this code in addition to those already generated?

[PawelDefee]

Hello,

I would not worry too much if you do properly take care of all exception situations and implement Cleanupstack/Leave processing in all the appropriate cases.

It can indeed be easily proved with little effort that the Series60 platform itself (especially Avkon) will leak memory in some situations when leave occurs. Your experience with the AppWizard-generated app supports this.

It is rather unfortunate because it also means that (at least some of) the in-built Series60 apps will not pass the lowmem test. On the other hand, it makes your job a little easier - just do your best and your app will pass the Symbian Signed certification

[josefaichhorn]

I really got the impression that Avkon itself leaks. The first problem I encountered was AddViewL. So how can we pass the lowmem test if the framework itself is not clean ???

[kamalneel82]

how to trace out in a code where these problem in the code lies:
this is result that i am getting after the lowmem testing tool.

Test Results...
Test Count: 37
Test Failed (%): 24
Mem Leak: 3
Requested free bytes,Exit category,Exit reason
40960,Kill,-4
41984,Kill,-4
43008,Kill,-4
44032,Kill,-4
45056,Kill,-4
48128,Kill,-4
49152,Kill,-4
50176,Kill,-4
51200,Kill,-4
68608,Etel Client Faul,8
69632,E32USER-CBase,40
70656,E32USER-CBase,40
71680,E32USER-CBase,40
72704,E32USER-CBase,40
73728,E32USER-CBase,40
74752,E32USER-CBase,40
75776,E32USER-CBase,40

plz help me out how to trace and fix these problems in a given code

[amphibolia]

Try to test low memory conditions on emulator. If you don't have any tools (e.g. Digia's test tool), you can try to simulate low memory condition. I did it that way: in 1st ConstructL allocate huge amount of memory on heap (free RAM size minus amount of memory you want to have left) and then see where it crashes. Repeat changing amount of free memory left.

At least it helped me to find few bugs in leaves handling and to reduce 30% of failure to 1%

E32USER-CBase,40 also gives a hint that you delete AO which has an outstanding request. If you don't have that many AOs in your code, you could also check all destructors if you cancel AO before deletion.