Read-only archive of the All About Symbian forum (2001–2013) · About this archive

LowMem and big app

10 replies · 0 views · Started 15 October 2005

Hello,

My application .app file is 272KBytes and 16.4KBytes .rsc file
Testing it on Nokia 6260 and latest LowMem version.

Default settings for LowMem: 22528 min free heap, 1024 increase
I got 2 crashes:
22528,KERN-EXEC,3
23552,KERN-EXEC,3
24576,Kill,-4
.....

Now testing application with 24,9KBytes app file and 476 bytes .rsc file
22528,Kill,-4
23552,Kill,-4
24576,Kill,-4

It is running correct.

First application (272KBytes) doesn't do anything in AppUi::ConstructL()
Resource file doent contain anything too, only one menu with Exit command.

AppUi::ConstructL()
{
BaseConstructL();

return;

}

RESOURCE EIK_APP_INFO
{
menubar = r_helloworldplus_menubar;
cba = R_AVKON_SOFTKEYS_OPTIONS_EXIT;
}

RESOURCE MENU_BAR r_helloworldplus_menubar
{
titles =
{
MENU_TITLE {menu_pane = r_helloworldplus_menu;}
};
}
RESOURCE MENU_PANE r_helloworldplus_menu
{
items =
{
// added the new Options menu command here
MENU_ITEM
{
command = EEikCmdExit;
txt = "Exit";
}
};
}

What is LowMem doing if I setup Min free heap to 1024 KBytes?
Simple App is crashing between 1024 - 15360 and no crash 16384- 17408 and
crash again 18432 - 21504.

Requested free bytes,Exit category,Exit reason
1024,KERN-EXEC,3
2048,KERN-EXEC,3
3072,KERN-EXEC,3
4096,KERN-EXEC,3
5120,KERN-EXEC,3
6144,KERN-EXEC,3
7168,KERN-EXEC,3
8192,KERN-EXEC,3
9216,KERN-EXEC,3
10240,KERN-EXEC,3
11264,KERN-EXEC,3
12288,KERN-EXEC,3
13312,KERN-EXEC,3
14336,KERN-EXEC,3
15360,KERN-EXEC,3
16384,Kill,-4
17408,Kill,-4
18432,KERN-EXEC,3
19456,KERN-EXEC,3
20480,KERN-EXEC,3
21504,KERN-EXEC,3
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,Kill,-4
31744,Kill,-4
32768,Kill,0

I'm completely lost what is LowMem testing at startup.
Any comments is very appreciate.

Best Regards,
Valentin Kalinin

> My application .app file is 272KBytes and 16.4KBytes .rsc file
> Testing it on Nokia 6260 and latest LowMem version.
>
> Default settings for LowMem: 22528 min free heap, 1024 increase
> I got 2 crashes:
> 22528,KERN-EXEC,3
> 23552,KERN-EXEC,3
> 24576,Kill,-4
> ....

It's a known 'feature' that KErrNoMemory leaves before
CEikAppUi::BaseConstructL() is called leads to a KERN-EXEC 3 panic.

This should be fixed in the future I presume. Also, just in case, make
sure you always use the latest version available.

--
David Caabeiro
www.PushL.com


"David Caabeiro" <[email protected]> wrote in message
news:CONYV00lFHA.1016@extapps30...[color=green]
> > My application .app file is 272KBytes and 16.4KBytes .rsc file
> > Testing it on Nokia 6260 and latest LowMem version.
> >
> > Default settings for LowMem: 22528 min free heap, 1024 increase
> > I got 2 crashes:
> > 22528,KERN-EXEC,3
> > 23552,KERN-EXEC,3
> > 24576,Kill,-4
> > ....

>
> It's a known 'feature' that KErrNoMemory leaves before
> CEikAppUi::BaseConstructL() is called leads to a KERN-EXEC 3 panic.
>
> This should be fixed in the future I presume. Also, just in case, make
> sure you always use the latest version available.
>
> --
> David Caabeiro
> www.PushL.com[/color]

I use LowMem Ver.1.4.0.
And there is no any KErrNoMemory what called by my application.
How can I prove that it is not my application fault to hest house?

> I use LowMem Ver.1.4.0.
> And there is no any KErrNoMemory what called by my application.
> How can I prove that it is not my application fault to hest house?

This situation has been reported to Symbian Signed, so they should be
already aware of it, either treating it as an exception, or making you
raise a waiver to the test house.
You should better either contact them or your test house in any case for
precisions.

--
David Caabeiro
www.PushL.com

>> How can I prove that it is not my application fault to hest house?

Also, for safety, make sure you allocate memory *after* calling
BaseConstructL()

--
David Caabeiro
www.PushL.com

One more "interesting" observation:

Initializing RFileLogger just after BaseConstructL() cause one additional
KERN-EXEC,3 instead of 24576,Kill,-4
User::LeaveIfError(iDbgLog.Connect());

iDbgLog.CreateLog(_L("AC"😉,_L("log.txt"😉,EFileLoggingModeAppend);

iDbgLog.Write(_L("CreateLogL"😉);

Regards,

Valentin

"David Caabeiro" <[email protected]> wrote in message
news:kdqBPG1lFHA.2828@extapps30...[color=green]
> > I use LowMem Ver.1.4.0.
> > And there is no any KErrNoMemory what called by my application.
> > How can I prove that it is not my application fault to hest house?

>
> This situation has been reported to Symbian Signed, so they should be
> already aware of it, either treating it as an exception, or making you
> raise a waiver to the test house.
> You should better either contact them or your test house in any case for
> precisions.
>
> --
> David Caabeiro
> www.PushL.com[/color]

"valentin" <[email protected]> wrote in message news😃d5v%2320lFHA.1016@extapps30...
>
> "David Caabeiro" <[email protected]> wrote in message
> news:CONYV00lFHA.1016@extapps30...[color=green][color=darkred]
> > > My application .app file is 272KBytes and 16.4KBytes .rsc file
> > > Testing it on Nokia 6260 and latest LowMem version.
> > >
> > > Default settings for LowMem: 22528 min free heap, 1024 increase
> > > I got 2 crashes:
> > > 22528,KERN-EXEC,3
> > > 23552,KERN-EXEC,3
> > > 24576,Kill,-4
> > > ....

> >
> > It's a known 'feature' that KErrNoMemory leaves before
> > CEikAppUi::BaseConstructL() is called leads to a KERN-EXEC 3 panic.
> >
> > This should be fixed in the future I presume. Also, just in case, make
> > sure you always use the latest version available.
> >
> > --
> > David Caabeiro
> > www.PushL.com[/color]
>
> I use LowMem Ver.1.4.0.
> And there is no any KErrNoMemory what called by my application.
> How can I prove that it is not my application fault to hest house?[/color]

http://www3.symbian.com/faq.nsf/0/E7FB1E0EDCEA88E380256FD600216593?OpenDocument

--
Tim Weis

+------------------------------------------------------+
| || |_) _ #symbian.dev |
| || | \ (_ EFnet |
+------------------------------------------------------+

IMHO, descripting problem in such way as it done in FAQ-1254 is bad idea.

Developer should waste his time to prove that his application is not fault
in LowMem design flaws.

Quote from FAQ-1254:
[color=green]
>>Focusing on CEikAppUi::BaseConstructL() issues, first put a User::Panic()
[/color]
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
....
[color=green]
>>You then place the panic immediately following the call to the AppUI
[/color]
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[color=green]
>>
>>
[/color]
How test house could check if I just "cheat" them sending this kind of
waiver request?
Best Regards,
Valentin

"Tim Weis" <[email protected]> wrote in message
news:a74XM82lFHA.1300@extapps30...
> "valentin" <[email protected]> wrote in message news😃d5v%2320lFHA.1016@extapps30...[color=green]
> >
> > "David Caabeiro" <[email protected]> wrote in message
> > news:CONYV00lFHA.1016@extapps30...[color=darkred]
> > > > My application .app file is 272KBytes and 16.4KBytes .rsc file
> > > > Testing it on Nokia 6260 and latest LowMem version.
> > > >
> > > > Default settings for LowMem: 22528 min free heap, 1024 increase
> > > > I got 2 crashes:
> > > > 22528,KERN-EXEC,3
> > > > 23552,KERN-EXEC,3
> > > > 24576,Kill,-4
> > > > ....
> > >
> > > It's a known 'feature' that KErrNoMemory leaves before
> > > CEikAppUi::BaseConstructL() is called leads to a KERN-EXEC 3 panic.
> > >
> > > This should be fixed in the future I presume. Also, just in case, make
> > > sure you always use the latest version available.
> > >
> > > --
> > > David Caabeiro
> > > www.PushL.com

> >
> > I use LowMem Ver.1.4.0.
> > And there is no any KErrNoMemory what called by my application.
> > How can I prove that it is not my application fault to hest house?[/color]
>
>
>[/color]
http://www3.symbian.com/faq.nsf/0/E7FB1E0EDCEA88E380256FD600216593?OpenDocument
>
> --
> Tim Weis
>
> +------------------------------------------------------+
> | || |_) _ #symbian.dev |
> | || | \ (_ EFnet |
> +------------------------------------------------------+
>
>

>Developer should waste his time to prove that his application is not fault
>in LowMem design flaws.

I am not involved in the development of LowMem itself, but I have been quite
heavily involved in some of the waiver/exception requests and various test spec
changes based on real-world feedback. Unfortunately these problems tend to be
system-level defects which are already in place and can't be 'fixed' or worked
around, hence it's not something we can do much about with LowMem itself...what
we have done is try and recognize the issue and treat it as a valid
exception/waiver. In practice, it shouldn't happen to every application hence
when it does come up, it is an exception.

>How test house could check if I just "cheat" them sending this kind of
>waiver request?

To be perfectly honest with you - nothing 😊 The way Symbian Signed is setup, it
strongly emphasizes issues of trust and responsibility. The ACS Publisher ID
identifies you uniquely as a developer so there is inherent traceability. If
people are found to be lying or 'fudging' results then of course we have a route
back to the ISV for an explanation and in the worst cases (e.g. with actual
harmful code) we can look at things like revoking SIS files, etc.

In reality, Signed has worked very well so far with a balance between developers
being trusted but also taking it upon themselves not to abuse that trust and
deliver good quality products.

In this case, I do sympathise with your problem...however, this should really be
a one-off issue. If you can show that the LowMem problems are coming from the
system not your application, you can present the same evidence again for any
future submissions too provided this is still case.

Regards,

Phil

Hi Phil,

Thanks for responce,

Anyway, I think "low memory" testing is very usefull, and I found some bugs
in destructors.

I have one more small question about LowMem tool.
I get in log file an error -1001. Is it should be interpreted as bug in
application?
As far as I understant it is thrown by TFindFile::FindWildByDir() function
in CEikonEnv::CreateBitmapL(),

35840,Kill,-1001
36864,Kill,-1001

Best Regards,
Valentin Kalinin

"Phil Spencer" <[email protected]> wrote in message
news:[email protected]...[color=green]
> >Developer should waste his time to prove that his application is not
[/color]
fault[color=green]
> >in LowMem design flaws.

>
> I am not involved in the development of LowMem itself, but I have been[/color]
quite
> heavily involved in some of the waiver/exception requests and various test

spec
> changes based on real-world feedback. Unfortunately these problems tend to

be
> system-level defects which are already in place and can't be 'fixed' or

worked
> around, hence it's not something we can do much about with LowMem

itself...what
> we have done is try and recognize the issue and treat it as a valid
> exception/waiver. In practice, it shouldn't happen to every application

hence
> when it does come up, it is an exception.
>[color=green]
> >How test house could check if I just "cheat" them sending this kind of
> >waiver request?

>
> To be perfectly honest with you - nothing 😊 The way Symbian Signed is[/color]
setup, it
> strongly emphasizes issues of trust and responsibility. The ACS Publisher

ID
> identifies you uniquely as a developer so there is inherent traceability.

If
> people are found to be lying or 'fudging' results then of course we have a

route
> back to the ISV for an explanation and in the worst cases (e.g. with

actual
> harmful code) we can look at things like revoking SIS files, etc.
>
> In reality, Signed has worked very well so far with a balance between

developers
> being trusted but also taking it upon themselves not to abuse that trust

and
> deliver good quality products.
>
> In this case, I do sympathise with your problem...however, this should

really be
> a one-off issue. If you can show that the LowMem problems are coming from

the
> system not your application, you can present the same evidence again for

any
> future submissions too provided this is still case.
>
> Regards,
>
> Phil

Opening CAgnModel cause this.

This line of code result Error -1001 or even KERN-EXEC,3 during testing with
LowMem.
I set User::Panic before this line of code and after.

35840 - before
> 35840,Kill,-1001
> 36864,Kill,-1001

37888, KERN_EXEC or -1001
38912 - after

TRAPD(err,iEntryModel->OpenL(KAgendaDocument,12*60,12*60,12*60));

Full code is:

iEntryModel=CAgnModel::NewL(this);

iPictureFactory=new(ELeave) TApaPictureFactory(aDocument->Process());

iEntryModel->SetPictureFactory(iPictureFactory);

iAgendaServ = RAgendaServ::NewL(); // allocate and construct server

User::LeaveIfError(iAgendaServ->Connect()); // connect to the agenda server

iEntryModel->SetServer(iAgendaServ); // set server pointer for model

//The agenda model can operate either in client or normal mode. Here we use
client mode

iEntryModel->SetMode(CAgnEntryModel::EClient);

TRAPD(err,iEntryModel->OpenL(KAgendaDocument,12*60,12*60,12*60)); // Open
file using server

if(err != KErrNone)

{

CEikonEnv::Static()->LeaveWithErrorContext(err,KRunAgenda);

}

iAgendaServ->WaitUntilLoaded();

Regards,
Valentin

"valentin" <[email protected]> wrote in message news:lLc07VDmFHA.1148@extapps30...
> Hi Phil,
>
> Thanks for responce,
>
> Anyway, I think "low memory" testing is very usefull, and I found some

bugs
> in destructors.
>
> I have one more small question about LowMem tool.
> I get in log file an error -1001. Is it should be interpreted as bug in
> application?
> As far as I understant it is thrown by TFindFile::FindWildByDir() function
> in CEikonEnv::CreateBitmapL(),
>
> 35840,Kill,-1001
> 36864,Kill,-1001
>
> Best Regards,
> Valentin Kalinin
>
> "Phil Spencer" <[email protected]> wrote in message
> news:[email protected]...[color=green][color=darkred]
> > >Developer should waste his time to prove that his application is not
[/color]
> fault[color=darkred]
> > >in LowMem design flaws.

> >
> > I am not involved in the development of LowMem itself, but I have been[/color]
> quite
> > heavily involved in some of the waiver/exception requests and various
[/color]
test
> spec[color=green]
> > changes based on real-world feedback. Unfortunately these problems tend
[/color]
to
> be[color=green]
> > system-level defects which are already in place and can't be 'fixed' or

> worked
> > around, hence it's not something we can do much about with LowMem

> itself...what
> > we have done is try and recognize the issue and treat it as a valid
> > exception/waiver. In practice, it shouldn't happen to every application

> hence
> > when it does come up, it is an exception.
> >[color=darkred]
> > >How test house could check if I just "cheat" them sending this kind of
> > >waiver request?

> >
> > To be perfectly honest with you - nothing 😊 The way Symbian Signed is[/color]
> setup, it
> > strongly emphasizes issues of trust and responsibility. The ACS
[/color]
Publisher
> ID[color=green]
> > identifies you uniquely as a developer so there is inherent
[/color]
traceability.
> If[color=green]
> > people are found to be lying or 'fudging' results then of course we have
[/color]
a
> route[color=green]
> > back to the ISV for an explanation and in the worst cases (e.g. with

> actual
> > harmful code) we can look at things like revoking SIS files, etc.
> >
> > In reality, Signed has worked very well so far with a balance between

> developers
> > being trusted but also taking it upon themselves not to abuse that trust

> and
> > deliver good quality products.
> >
> > In this case, I do sympathise with your problem...however, this should

> really be
> > a one-off issue. If you can show that the LowMem problems are coming
[/color]
from
> the[color=green]
> > system not your application, you can present the same evidence again for

> any
> > future submissions too provided this is still case.
> >
> > Regards,
> >
> > Phil

>
>[/color]