NewLC - Simulating LowMem (low memory stress tool) on the emulator - Comments

Re: Simulating LowMem (low memory stress tool) on the emulator

mikaraento — Mon, 08 Jan 2007 08:42:45 +0100

You shouldn't get an access violation (although you will, if the framework code runs out of memory).

Your app should exit with -4 if it runs out of memory and can't recover. I couldn't actually run my app on the 3rd edition satisfactorily, since the framework code crashes so easily, so you'll have to investigate how to properly propagate the error yourself.

Re: Simulating LowMem (low memory stress tool) on the emulator

euroq — Thu, 04 Jan 2007 22:11:19 +0100

Thanks for the great advice! I have an exciting program which simulates the LowMem app on the emulator now. (Sometimes you can see when something fails within their code due to low memory, but which would normally work perfectly given enough memory... looks like at least the emulator version of the OS needs some better error handling!)

There's only one thing, though. With the actual LowMem app given by Symbian, when the app runs out of memory and a message box appears saying "Out of memory", the LowMem app steals back the focus and asks you if you want to continue the test. So, obviously the LowMem app is aware when the thread has run out of memory. LowMem will close down the app (I can see my destructors being called on the device because of log files).

My app in particular is tricky because there is an APP and a LIB, and also the LIB uses networking. It seems as if both the GUI code in the APP, and the networking code in the LIB are running out simultaneously (they're active objects after all).

Well, the exception handling of RThread probably doesn't work on the emulator (because windows always catches things like access violations). At least, I tried it. So, in my version of the LowMem tool I run the threads as an active object, with another timer active object in the background. If the thread hasn't ended normally after 15 seconds, the timer shuts it down with either a RThread::Kill() or a RThread::Terminate() call. (I've tried them both, they both seem to do exactly the same thing)

The problem is, RThread::Kill and Terminate immediately stop the thread... no destructors are called. Does anyone have any idea how LowMem does it? i.e. forces the app to shut down when you tell it to continue the test? Because that's where my app is causing KERN-EXEC 3 errors on the device.

Thanks,
-euroq

Re: Simulating LowMem (low memory stress tool) on the emulator

mikaraento — Thu, 21 Dec 2006 15:05:16 +0100

The correct way is to spawn a thread to run the application in. When creating the thread, you specify the maximum heap.

On 9.1, you have to add support code to your application's E32Main. I do it like:

Code:

// in the tester
RChunk heapc;
User::LeaveIfError(heapc.CreateGlobal(KHeapName, 20, 20));
CleanupClosePushL(heapc); pushed++;
TInt *heapp=(TInt*)heapc.Base();
*heapp=iCurrentMaxHeapSize;
RProcess thread;
TInt err=thread.Create(KExeName, KNullDesC);

// in the app
TInt RunApplication(TAny*)
{
return EikStart::RunApplication(NewApplication);
}

GLDEF_C TInt E32Main()
{
RChunk heapc;
TInt err=heapc.OpenGlobal(_L("contextcontacts_heap"), ETrue);
if (err!=KErrNone) {
return EikStart::RunApplication(NewApplication);
}
RThread thread;
TInt heap=*(TInt*)heapc.Base();
heapc.Close();
err=thread.Create(_L("contextcontacts2"),
&RunApplication, // thread's main function
20*1024, /* stack */
heap, /* min heap */
heap, /* max heap */
0,
EOwnerProcess);
if (err!=KErrNone) return err;
thread.SetPriority(EPriorityNormal);
TRequestStatus s;
thread.Logon(s);
thread.Resume();
User::WaitForRequest(s);
TExitCategoryName n=thread.ExitCategory();
TInt reason=thread.ExitReason();
TExitType exittype=thread.ExitType();
thread.Close();
if (exittype==EExitPanic) {
RDebug::Print( n );
User::Panic( n, reason);
}
return reason;
}

On pre-9.1, you can fully encapsulate the code in the tester:

Code:

void run_app_inner()
{
TInt pushed=0;

TFileName fn=_L("z:\\system\\apps\\context_log\\context_log.app");
CApaCommandLine* cmd=CApaCommandLine::NewL(fn);
/* RunAppInsideThread deletes the command line */
EikDll::RunAppInsideThread(cmd);

CleanupStack::PopAndDestroy(pushed);
}

TInt run_app(TAny*)
{
CTrapCleanup* cleanupStack = CTrapCleanup::New();
TRAPD(err, run_app_inner());
delete cleanupStack;
return err;
}

// and then
RThread thread;
TInt err=thread.Create(_L("context_log"),
&run_app, // thread's main function
20*1024, /* stack */
0, // parameters
0,
NULL,
heap, /* min heap */
heap, /* max heap */
EOwnerProcess);

On both you then follow in the tester with:

Code:

User::LeaveIfError(err);
thread.SetPriority(EPriorityNormal);
TRequestStatus s;
thread.Logon(s);
thread.Resume();
User::WaitForRequest(s);
msg=_L8(" done: ");
msg.Append(thread.ExitCategory());
msg.Append(_L8(" "));
msg.AppendNum(thread.ExitReason());
msg.Append(_L8("\n"));

That's the basic idea.

Re: Simulating LowMem (low memory stress tool) on the emulator

alh — Thu, 21 Dec 2006 14:24:58 +0100

Havn't used these functions, but from reading the documentation, maybe the problem is it gives the _current_ max, not counting in that your heap may expand.

A thread has a min and a max limit for its heap, when the thread is started, it gets the min size of the heap, and if a call to alloc doesn't fit, it will expand it, in increments, until it hits the max limit.

So if it hasn't expanded yet when you call that function, and then the next allocation will make it expand, you would get the result you are experiencing.

Simulating LowMem (low memory stress tool) on the emulator

euroq — Wed, 20 Dec 2006 23:10:56 +0100