"petxolobo" <[email protected]> wrote in message
news:%23GjgblVPGHA.3396@extapps30...
> Thanks for your response.
>
> I seem to have found part of the problem but it is really wierd. When i
> install LowMem i expect it to configure the settings according to whatever
> phone i install it on. Specifically the value "Min free heap" is supposed
> to be different on different devices and what�s more I should never modify
> that value as that is what the test house will use. Ok so that�s all
> fine.
>
> The problem is that i am in Spain and as such my phone is in Spanish. Now
> the good news is that LowMem installs on my phone in Spanish and in so
> doing it gives a very good impresion of being localised for Spanish.
> However when i do this the configuration setting for "Min free heap" is
> always set to 1024 which is clearly the source of my excessive
> KERN-EXECing.
This means that the phone isn't recognised. Contact Symbian Signed. They can
give you a more realistic value for your device, if you tell them what it
is.
> If anybody reading this has any sway with the authors of LowMem can they
> get them to raise a bug report on this.
>
> Moving on....
>
> I still get KERN-EXEC 3 but now i have isolated the issue to the
> BaseConstructL. I wanted to try the suggestion you made regarding the
> document creation but i ran into some issues (and here i might be exposing
> my lack of knowledge regarding the way series 60 apps are run up).
>
> At the moment my document is created in the following method
>
> CApaDocument* CMyProjectApp::CreateDocumentL()
> {
> return CMyProjectDocument::NewL( *this );
> }
>
> This method must be implemented or the app won�t compile also it gets
> called prior to the CAppUi::ConstructL. So what i can�t see is how i stop
> the document getting created prior to the BaseConstructL. I did try just
> returning NULL from the above method and commenting the document creation
> but this just caused the app to fall over straight away. so in conclusion
> i was unable to try this.
Change the code to:
CApaDocument* CMyProjectApp::CreateDocumentL()
{
return new (Eleave) CMyProjectDocument( *this );
}
CMyAppUi::ConstructL()
{
BaseConstructL()
CMyDocument* doc = static_cast<CMyDocument*>(Document());
doc->ConstructL();
//
This is only relevant when you doe actual work in the document's
ConstructL(). If it is empty, don't bother.
> Then i tried something else. My thinking was that if i was getting a
> KERN-EXEC 3 from the BaseConstructL because it wasn�t handling the low
> memory conditions well then what i could do was allocate and then free a
> chunk of memory just prior to the BaseConstructL. that way what i should
> see is the system leaving with KErrNoMemory because it couldn�t allocate
> the memory up to the point where it could however, since it then imediatly
> deallocate the memory i should now have enough to get me through the
> BaseConstructL. I tried allocating the memory using HBufC. Ok, so it�s
> not especially elegant but it should work right? Wrong. What i saw was
> that the test failed with KERN-EXEC 3 in the call to the HBufC::NewLC.
>
> If you have any further thoughts on this i would be grateful.
Tried this trick myself too, but even earlier, before creating the
Application, and I was using User::AllocL(), followed by a User::Free(). It
does work fine on the devices I tried this. The problem is that such a trick
hides real problems in your startup code.
Now, why does this work?
LomMem starts an app repeatedly, and each time gives it a bit more memory.
By doing a User::AllocL() asking lots of memory, this User::AllocL() fails,
until LowMem has given the app enough memory to start with.
When there is not enough memory, the app simply doesn't get created and
therefore cannot fail. When there is enough memory, the app gets created and
there is enough heap for all other objects too.
But as I said, this hides real problems in *your* initalisation code. And
when there are quality problems in your initialisation code, there are
quality problems in the rest of *your* code too. This is something to keep
in mind when making the business decision of fooling the quality control
tool Lowmem.
Now, the advantage of moving document second phase construction to a place
after BaseConstructL() is that it makes it easier for you to separate
problems in your startup code from problems in the Symbian startup code.
Everything that happens in your code before BaseConstructL() is trivial, and
can be verified for correctness rather easily.
--
Sander van der Wal
www.mBrainSoftware.com
> Cheers
>
> PL
>
>
> "Sander van der Wal" <[email protected]> escribi� en el mensaje
> news:N%2378n8PPGHA.2236@extapps30...[color=green]
>>
>> "petxolobo" <[email protected]> wrote in message
>> news:MAjNqeHPGHA.1040@extapps30...[color=darkred]
>>> My LowMem test fails with Kern-Exec 3 under the lowest memory
>>> conditions. I have tried adding my own User::Panic method into the
>>> startup code to try to isolate the problem. however i have taken it
>>> right back to the earliest point of exection that i can find ie i put
>>> the User::Panic in just before the call to create the CAknApplication
>>> class (ie before the document class or the appui class get created) and
>>> i still get KERN-EXEC 3 for the first several runs through before it
>>> hits my User::Panic.
>>>
>>> Does anyone have any thoughts what the problem might be or where i
>>> should be looking?
>>
>> The framework itself doesn't always leave when it finds a nulll pointer,
>> it uses the pointer and then crashes.
>>
>> There is not much you can do about this, apart from following the rule
>> that LowMem should use the default amount of memory.
>>
>> Delaying object construction until after the appui's BaseConstructL()
>> call will also make your life much easier. The easiest wat to do this is
>> by delaying your document's ConstructL
>>
>> CAppUi::ConstructL()
>> {
>> BaseConstructL()
>> CDoc* doc = static_cast<CDoc*>(Document());
>> doc->ConstructL();
>>
>> /// etc
>>
>> This trick works because CEikDocument doesn't have a virtual
>> ConstructL(), so the framework cannot call it and all the document's
>> virtual methods that are called before BaseConstructL() (CreateAppUiL())
>> can work with a partly constructed document.
>>
>> --
>> Sander van der Wal
>> www.mBrainSoftware.com
>>[/color]
>
>[/color]