×

Discussion Board

Results 1 to 11 of 11
  1. #1
    Registered User
    Join Date
    Jun 2007
    Location
    Poland
    Posts
    15

    Thumbs down MMF-related ALLOC panic

    Code:
    __UHEAP_MARK;
    
    CMMFFormatSelectionParameters* formats =
    	CMMFFormatSelectionParameters::NewLC();
    	
    CMMFControllerPluginSelectionParameters* plugins =
    	CMMFControllerPluginSelectionParameters::NewLC();
    	
    RMMFControllerImplInfoArray controllers;
    CleanupResetAndDestroyPushL( controllers );
    	
    plugins->SetRequiredPlayFormatSupportL( *formats );
    plugins->ListImplementationsL( controllers );
    
    CleanupStack::PopAndDestroy( 3, formats );
    
    __UHEAP_MARKEND;
    The above code snippet causes the ALLOC panic. This happens at least in emulator debug builds for S60 3rd FP2.
    The HookLogger highlights
    Code:
    plugins->ListImplementationsL( controllers );
    line, yet
    Code:
    plugins->SetRequiredPlayFormatSupportL( *formats );
    seems to allocate something on the heap as well. Calling manually
    Code:
    controllers.ResetAndDestroy();
    did not help. Does anybody have idea how to fix it?

    Thanks in advance!


    Regards.
    Last edited by po; 2008-05-08 at 22:19.
    Regards and good luck! ;)

  2. #2
    Registered User
    Join Date
    Jun 2007
    Location
    Poland
    Posts
    15

    Re: MMF-related ALLOC panic

    Ok, so at least I'm sure that the leaking line is:
    Code:
    plugins->ListImplementationsL( controllers );
    After commenting it, no panic occured.
    Regards and good luck! ;)

  3. #3
    Nokia Developer Moderator
    Join Date
    Feb 2006
    Location
    Oslo, Norway
    Posts
    28,734

    Re: MMF-related ALLOC panic

    UHEAP_MARK/MARKEND macros can help but also can be evil, and it higly depends on the situation where you use them. Many things can happen when you start using a library - for example ECOM plugins (or just their descriptors) can be loaded, and it is absolutely not sure that they are unloaded when you release the related handlers/objects. Memory leaks can be reliably detected only on application shutdown (after CCoeStatic-s, TLS-s have been released), until then anything can appear to be a memory leak.
    For example L-methods often use the Cleanup Stack, and if the Cleanup Stack gets extended between a UHEAP_MARK-MARKEND pair, it is also going to be detected as a memory leak (since the Cleanup Stack resides in your heap).

  4. #4
    Registered User
    Join Date
    Jun 2007
    Location
    Poland
    Posts
    15

    Re: MMF-related ALLOC panic

    Quote Originally Posted by wizard_hu_ View Post
    UHEAP_MARK/MARKEND macros can help but also can be evil (...)
    Thanks for reply! The problem is that I get ALLOCs without UHEAP macros too. And they dissappear after commenting "ListImplementationsL". The same problem is with the code snippet below:

    Code:
    CMMFFormatDecodePluginSelectionParameters* plugins =
    	CMMFFormatDecodePluginSelectionParameters::NewLC();
    	
    CMMFFormatSelectionParameters* formatSelParams =
    	CMMFFormatSelectionParameters::NewLC();
    	
    plugins->SetRequiredFormatSupportL( *formatSelParams );
    	
    RMMFFormatImplInfoArray supportedFormats;
    CleanupResetAndDestroyPushL( supportedFormats );
    plugins->ListImplementationsL( supportedFormats );
    	
    CleanupStack::PopAndDestroy( 3, plugins );
    I run this on FP1 as well and results are the same.
    Last edited by po; 2008-04-29 at 14:37.
    Regards and good luck! ;)

  5. #5
    Nokia Developer Moderator
    Join Date
    Mar 2003
    Posts
    1,213

    Re: MMF-related ALLOC panic

    Could this be an emulator-specific problem? We investigated the memory consumption of the code snippet "CS000899 - Finding audio and video formats supported by the phone" ( http://wiki.forum.nokia.com/index.ph...d_by_the_phone ) on N93 before and after retrieving format information and the result seemed to be that all reserved memory was also freed.

    For checking how much free memory is available, we used TSS000038:
    http://wiki.forum.nokia.com/index.ph...s_available%3F

    #include <e32hal.h>
    TMemoryInfoV1Buf info;
    UserHal::MemoryInfo(info);
    TInt freeMemory = info().iFreeRamInBytes;

  6. #6
    Registered User
    Join Date
    Jun 2007
    Location
    Poland
    Posts
    15

    Re: MMF-related ALLOC panic

    Quote Originally Posted by seppo_fn View Post
    Could this be an emulator-specific problem? We investigated the memory consumption of the code snippet "CS000899 - Finding audio and video formats supported by the phone" ( http://wiki.forum.nokia.com/index.ph...d_by_the_phone ) on N93 before and after retrieving format information and the result seemed to be that all reserved memory was also freed.

    For checking how much free memory is available, we used TSS000038:
    http://wiki.forum.nokia.com/index.ph...s_available%3F

    #include <e32hal.h>
    TMemoryInfoV1Buf info;
    UserHal::MemoryInfo(info);
    TInt freeMemory = info().iFreeRamInBytes;
    Hi Seppo,

    I don't think this is an emulator-specific problem. Sorry for my bad estimate of the situation. My friend an me were able to run this snippet pulled into HelloWorld's ConstructL in AppUi without ALLOC (on MR and FP1). In my case, the problematic code runs inside a thread (not application's main thread). This caused me to try to run my code inside main application's thread too, and guess...everything worked fine! I have no idea why?? o_O So either I've failed with proper thread usage or there are some issues with using such code inside another than application's main thread. I will update this topic when discovered any solution or more info.

    If you or anybody had any idea why this would fail in another thread, I'd be glad to see it.

    This is my thread's entry point:
    Code:
    /*static*/ TInt CActiveDerivedClass::ThreadEntryPoint(
        TAny* /*aParameters*/ )
    {
        CTrapCleanup* cleanupStack = CTrapCleanup::New();
        CActiveScheduler* scheduler = new CActiveScheduler();
    
        if( cleanupStack && scheduler )
        {	
    	TRAPD(err,	
    	    CleanupStack::PushL( scheduler );
    	    CActiveScheduler::Install( scheduler );
    	
    	    CSomeClass1* someClass1 = CSomeClass1::NewLC();
    	    CSomeClass2* someClass2 = CSomeClass2::NewLC();
    	    CSomeClass3* someClass3 = CSomeClass3::NewLC();
    
    // PLEASE NOTE: CSomeClass3  class has a member, which calls
    // problematic code in it's ConstructL and in consequence leaks;
    // this doesn't happen, when CSomeClass3 is created in AppUi's ConstructL()
    			
    	    DoSomethingL();
    			
    	    for( TInt i = 0; i < someCount; ++i )
    	    {
    	        TRAPD( err, DoSomethingElseL() );
    	        if( KErrNone == err )
    	        {
    	            DoAnotherThingL();
    		}
    	    }
    
    	    CleanupStack::PopAndDestroy( 4, scheduler );
            );		
    
    	delete cleanupStack;
    
    	return err;
        }
    	
        return KErrNoMemory;
    }
    // There's no CActiveScheduler::Start() because the thread hangs.
    // On the other hand, I could not run the code without CBase-44
    // until CActiveScheduler was created.
    Thanks and regards,
    Piotr
    Last edited by po; 2008-05-04 at 22:49.
    Regards and good luck! ;)

  7. #7
    Registered User
    Join Date
    Dec 2006
    Posts
    2,280

    Re: MMF-related ALLOC panic

    It looks at first glance like the problem is likely to be related to using active objects without a running scheduler.

    You need to set at least one object active before you start the scheduler or nothing will ever run (as you are seeing with the thread hanging).

    Odd case though.

    Good luck!

    Sorcery

  8. #8
    Registered User
    Join Date
    Jun 2007
    Location
    Poland
    Posts
    15

    Re: MMF-related ALLOC panic

    Quote Originally Posted by Sorcery-ltd View Post
    It looks at first glance like the problem is likely to be related to using active objects without a running scheduler.

    You need to set at least one object active before you start the scheduler or nothing will ever run (as you are seeing with the thread hanging).

    Odd case though.

    Good luck!

    Sorcery
    Yup, it might be the problem, yet it seems not to be it. CSomeClass2 has as it's member CMdaAudioPlayerUtility, which during construction most probably adds some active obcject to active scheduler, however it doesn't set it's state to active, because the thread would hang after call to CActiveScheduler::Start(), right?
    And the problematic code (that mentioned in previous posts) for me is called during CSomeClass3 construction.

    And to be honest, I believe my code doesn't work because of my error. Unfortunately I have no idea why... :/

    Thanks!

    Regards,
    Piotr
    Regards and good luck! ;)

  9. #9
    Registered User
    Join Date
    Dec 2006
    Posts
    2,280

    Re: MMF-related ALLOC panic

    Hi,

    I don't think this is likely to be entirely your fault. If the code doesn't leak in the main thread and does in another thread then it would seem that there is some problem in the firmware (unless you are ignoring an error code returned somewhere). Just because the scheduler isn't started doesn't mean there's an excuse for memory leaks - the cleanup code for the classes you use shouldn't assume that a scheduler is running (all assuming this is the problem).

    So, I'd still suggest that you work out how to get the scheduler working and see if it fixes the memory leak with the plugin selection. As far as the MMF is concerned there shouldn't really be any other difference between the main thread and any you create afterwards.

    Sorcery

  10. #10
    Registered User
    Join Date
    Jun 2007
    Location
    Poland
    Posts
    15

    Re: MMF-related ALLOC panic

    Quote Originally Posted by Sorcery-ltd View Post
    Hi,

    I don't think this is likely to be entirely your fault. (...)

    Sorcery
    Hi,

    Ok, I will try to Start() active scheduler.

    Regards,
    Piotr
    Last edited by po; 2008-05-07 at 00:21.
    Regards and good luck! ;)

  11. #11
    Registered User
    Join Date
    Jun 2007
    Location
    Poland
    Posts
    15

    [WORKAROUNDED] Re: MMF-related ALLOC panic

    I could not manage to start active scheduler loop. As a result, the additional thread is completely removed from my code. Now I use an active obcject with long synchronous task divided into atomic tasks running as iterations in separate RunL calls. It is slower and worse solution, but at least works without the ALLOC.

    Thanks for help once again!

    Regards,
    Piotr
    Last edited by po; 2008-05-08 at 22:20.
    Regards and good luck! ;)

Similar Threads

  1. Using Bluetooth serial port in MIDlets (nokia 9500 issue)
    By orsteglasy in forum Mobile Java Networking & Messaging & Security
    Replies: 11
    Last Post: 2007-10-07, 21:49
  2. Panic ALLOC in CBrCtlInterface::LoadUrlL
    By ggomeze in forum Symbian
    Replies: 15
    Last Post: 2007-09-17, 21:25
  3. ALLOC 0 panic -- CDesC16ArrayFlat leaks
    By bnvaikos in forum Symbian
    Replies: 5
    Last Post: 2007-07-09, 10:21
  4. Strange ALLOC Panic (Symbian 9)
    By isemenov in forum Symbian
    Replies: 6
    Last Post: 2006-12-21, 10:28
  5. ALLOC Panic found, Please help...
    By yogesh14 in forum Symbian User Interface
    Replies: 22
    Last Post: 2006-11-27, 13:13

Posting Permissions

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