×

Discussion Board

Results 1 to 11 of 11
  1. #1
    Regular Contributor
    Join Date
    Feb 2004
    Posts
    51

    Memory Leak in S60 V1 Avkon

    Hello,
    Symbian Signed Lowmem tool gave me the impression that Avkon (in particular CAknViewAppUi::AddViewL) itself is not clean. As I tested my own (non-trivial) application I wanted exclude all possibilties of doubt and switched to one of the "trivial" examples provided by Nokia.

    Very surprisingly (at least for me) it turned out that the example app (and therefore AddViewL) was OK.
    However, I found out that there was always enough free memory for AddViewL to succeed (because some parts executed before AddViewL already freed some memory).
    So I tried to allocate parts of the memory (to be more precise I allocated the biggest available memory blocks).
    It turned out that AddViewL allocates around 200 bytes the first time it is called. If it fails then there is a mem leak.

    So my provocative question is: How can we pass Symbian Signed lowmem test if the framework itself sucks ?

  2. #2
    Super Contributor
    Join Date
    Mar 2004
    Location
    Czech Republic
    Posts
    2,037
    Hi,

    should you put the leaking code here? I want to test it too.
    Thanx
    STeN

  3. #3
    Regular Contributor
    Join Date
    Feb 2004
    Posts
    51
    you are right. I took the multiviews example from S60 V1.2 SDK.
    A first glance over the code (CMultiViewsAppUi.cpp::ConstructL) will show you that there is a mistake in this simple example code. iAppView1 and iAppView2 are not pushed on the cleanup stack. So make sure that you fix this before you do the first test.

    So it should be something like this.

    void CMultiViewsAppUi::ConstructL()
    {
    BaseConstructL();

    iAppView1 = CMultiViewsView1::NewLC();
    iAppView2 = CMultiViewsView2::NewLC();

    AddViewL(iAppView2); // transfer ownership to base class
    CleanupStack::Pop(iAppView2);

    AddViewL(iAppView1); // transfer ownership to base class
    CleanupStack::Pop(iAppView1);

  4. #4
    Regular Contributor
    Join Date
    Feb 2004
    Posts
    51
    Using this you will not be able to show a mem leak (I tested it on NGage QD) ... simply because there is always enough memory to execute AddViewL (probably because some things are allocated and then freed before AddViewL is executed). So it is pretty hard to test AddViewL itself. I found out that in my case there is always > 600 bytes of free memory before AddViewL is called.
    So what I tried first was to request those 600 bytes ... but it did not prove anything (i.e. that there is a mem leak) - it simply moved the problem backwards (in terms of heap size). Requesting 600 bytes (User::Alloc) means that there must be a single memory block of 600 bytes. So smaller blocks which are already available are not used.

    So I had a look at the biggest available memory blocks and tried to eat them up. The resulting code looks like this ...

  5. #5
    Regular Contributor
    Join Date
    Feb 2004
    Posts
    51
    CMultiViewsAppUi::CMultiViewsAppUi()
    {
    iMem1 = NULL;
    iMem2 = NULL;
    iMem3 = NULL;
    }


    CMultiViewsAppUi::~CMultiViewsAppUi()
    {
    delete iMem1;
    delete iMem2;
    delete iMem3;
    }


    void CMultiViewsAppUi::ConstructL()
    {
    BaseConstructL();


    iAppView1 = CMultiViewsView1::NewLC();
    iAppView2 = CMultiViewsView2::NewLC();


    iMem1 = User::AllocL(380);
    iMem2 = User::AllocL(250);
    iMem3 = User::AllocL(180);

    AddViewL(iAppView2); // transfer ownership to base class
    CleanupStack::Pop(iAppView2);

    AddViewL(iAppView1); // transfer ownership to base class
    CleanupStack::Pop(iAppView1);

    SetDefaultViewL(*iAppView1);
    }

  6. #6
    Regular Contributor
    Join Date
    Feb 2004
    Posts
    51
    iMem1 2 3 is of type TAny*

  7. #7
    Registered User
    Join Date
    Mar 2003
    Posts
    18
    1.
    I think that not pushing iAppView1 on a ClenaupStack is ok, if iAppView1 is a a data member of CMultiViewsAppUi (which it is)
    so calling
    iAppView1 = CMultiViewsView1::NewL(); .
    is ok.

    2.
    It turned out that AddViewL allocates around 200 bytes the first time it is called. If it fails then there is a mem leak.
    Q: Did you mean "mem leak" as found by LowMem or "mem leak" as causing app to crash, like KERN-EXEC 3 or such

    All the best
    Og

  8. #8
    Regular Contributor
    Join Date
    Feb 2004
    Posts
    51
    I mean mem leak as found by lowmem.

    Note that if you put ErrRd in bootdata it is not reported for a simple reason. It seems that mem leaks are not reported until app ui ConstructL returns. So you can only find it with lowmem tool.

  9. #9
    Registered User
    Join Date
    Mar 2003
    Posts
    18
    What do you mean by "it is not reported for a simple reason" ?

    As for mem_leaks showing only after AppUI::constructL : it is true in my case: memLeaks appear after UI and all Views are constructed, databases loaded and only after last timeout of a splash screen redraws.

    Also when LowMem fails with KERN-EXEC I can usually emulate this by putting __UHEAP_FAILNEXT at apropriate place at the construction time, in the emulator. (I say usually since there are few KERN-EXECs I cannot cath (see other thread 55980))

    Do you know how to catch LowMem's memLeaks using emulator?
    Is "So you can only find it with lowmem tool" answer to that :-)

    It would be great if someone would write, in detail, all steps Framework performs at application launch....

    All the best
    Og

  10. #10
    Regular Contributor
    Join Date
    Feb 2004
    Posts
    51
    __UHEAP_FAILNEXT vs. lowmem

    Don't forget that these are different things. Lowmem defines an upper heap limit (so if an allocation fails and something is popped off the cleanupstack and destroyed there will be free memory again) whereas __UHEAP_FAILNEXT defines an allocation failure rate.
    "rate" and "heap size limit" are two different things.

    Best,
    Joe

  11. #11
    Registered User
    Join Date
    Mar 2003
    Posts
    18
    True,

    If something fails and than s/thing is popped from the stack there will be free memory again so LowMem will go few steps further untill final crash ...

    On the other hand if one ensure that all allocs that fail Leave (using new (ELeave) and NewL etc...) than the first point of reaching the high limit (that will cause Leave which will hopefully propagate to the Framework or some TRAP you set) would be the same as the point where you set SETFAIL

    ( Actually I use __UHEAP_SETFAIL and not FAILNEXT to ensure all allocs from some point fail. )
    Again, the assumption is that all allocations are written correctly. :-)

    Anyhow, How come that memLeak that LowMem finds does not cause app to crash, at least at destruction time?

    All the best
    Og

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×