MMF-related ALLOC panic

[po]

__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

plugins->ListImplementationsL( controllers );

line, yet

plugins->SetRequiredPlayFormatSupportL( *formats );

seems to allocate something on the heap as well. Calling manually

controllers.ResetAndDestroy();

did not help. Does anybody have idea how to fix it?

Thanks in advance!


Regards.

[po]

Ok, so at least I'm sure that the leaking line is:

plugins->ListImplementationsL( controllers );

After commenting it, no panic occured.

[wizard_hu_]

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).

[po]

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:

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.

[seppo_fn]

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;

[po]

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:

/*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

[Sorcery-ltd]

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

[po]

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

[Sorcery-ltd]

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

[po]

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

[po]

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