"Gernot Schrumpf" <[email protected]> schreef in bericht
news:L7NkvtEuFHA.1196@extapps30...
> Hello,
>
> our app failed the MEM-01 test and now I'm trying to fix the problems.
> Since there is no emulator version of LowMem it is very difficult. The
> LowMem user guide suggests to manually allocate memory after
> BaseConstructL(). I've tried it with different allocation sizes in the
> emulator, but the app closes with an OOM-message instead a KERN-EXEC.
You also need to free that memory. The trick is that you simulate a memory
shortage, by reducing the size of the heap.
A much better way to test your statup code is by executing pieceis of it
under a test harnass on the emulator. I'll give some examples
CApaDocument* CPdfPlusApplication::CreateDocumentL()
{
//TInt count = 22;
//__UHEAP_FAILNEXT(count);
CPdfPlusDocument* doc = new(ELeave) CPdfPlusDocument(*this);
CleanupStack::PushL(doc);
doc->ConstructL();
CleanupStack::Pop(); // doc
return doc;
}
Uncomment the count and _UHEAP lines, set count to 0 and set a breakpoint on
the first executable line after count. Start your program in the debugger.
Because count == 0 at the first run, allocation will fail immediately. Press
F5.
Run the program again , and set count to 1 in the debugger. Press F5. The
program will fail a bit later. Continue this way.
Eventually the program will either pass the method completely, or you will
find an OOM error. When you see an OOM error (you get the allocation panic),
set count to that number in the code, recompile and use the debugger to
trace all the allocations in the usual way. This will quickly lead you to
the allocation that isn't freed.
Manually tracking this is hard work, there is an easier way. The counting
can be done in a for loop, but you will have to add special code to do this.
Below is an example on how this could look like. There is one important
thing to do here and that is making sure the you test a single function that
allocates the resource. The reason is that the TRAPD() can only correctly
handle a single function, not a statement sequence. Also, make sure you also
use the single function in your code, or make the 'production' function in
such a way that you can *prove* it behaves correctly. It is very easy to
*prove* that the the NewLC construction function is OOM-correct when you
have tested the NewL function and the NewL function is build in the usual
way from the NewLC function, for instance.
void CPdfPlusAppUi::ConstructFileViewL()
{
#if 0 // def __WINS__
//
// check reading and destroying a CPdfFileView
//
{
__UHEAP_MARK;
TInt start = 0;
TInt err;
CPdfFileView* fileView = 0;
for (register TInt i = start; ; i++)
{
__UHEAP_FAILNEXT(i);
__UHEAP_MARK;
TRAP(err, fileView = CPdfFileView::NewL(this));
delete fileView; // delete when construction succeeds, otherwise you
will get an OOM
__UHEAP_MARKENDC( i < 27 ? 0 : 2);
fileView = 0;
if (err != KErrNoMemory)
break;
}
__UHEAP_MARKEND;
__UHEAP_RESET;
// other errors are still bad
User::LeaveIfError(err);
}
#endif
iFileView = CPdfFileView::NewLC(*this, iFileViewState);
AddViewL(*iFileView);
CleanupStack::Pop(iFileView);
}
And yes, you will find OOM problems in your appview-allocation. For example
, when there is ownership-transfer to the view server.
By dividing the appui::ConstructL() in a sequence of allocation functions
like this, you can easily test for OOM problems in a half-automated way.
When you are satisfied yje code is OOM-correct, you can comment the test
code out.
> The next thing I've tried is to check free memory at start up using
> HAL::Get(HALData::EMemoryRAMFree, iFreeRam), but the value returned
> doesn't seem to reflect the availabled memory for my app.
You should be interested in the heap size of your own process.
If you want to be really nasty, allocate the memory using User::Alloc() and
immediately User::Free() it in NewApplication(), before creating the
application.
LOCAL_C CApaApplication* NewApplication()
{
void* mem = User::Alloc(KLoadsOfMem);
if (0 == mem)
return 0; // make it look as if CMyApplication is a big class
User::Free(mem);
mem = 0;
return new CMyApplication;
}
Super nasty is left as an exercise.
--
Sander van der Wal
www.mBrainSoftware.com
> BTW: One point, that really confuses me, are the LowMem settings. The user
> guide says, that factory settings are required for the test, which are
> 1024 min free heap on all phones that I have. In contrast to that the test
> house has tested the app with 40960 bytes min free heap. Which value is
> correct for testing?
>
> How do you procede to find and correct such problems?
>
> Regards,
> Gernot
>