memory leak in xprofile

[oxidative]

hi there,

I'm using the xprofile extension to get the currently active profile. But since my script is supposed to run in the background forever, I noticed pretty soon that something is leaking, I get a "memory full" message after some time.

I've put up a minimal example to reproduce the leak:

import e32, sysinfo, xprofile

while 1:
    currentProfile = xprofile.get_ap()
    print u"free_ram()=%d" % (int(sysinfo.free_ram())/1024)
    e32.ao_sleep(0.1)

I assume that the problem is located within the python extension itself (no proper cleanup or something). The code in question is here:

// WORKS !
static PyObject* xprofile_get_apx(PyObject* /*self*/, PyObject* /*args*/)
{
  TInt ret;
  
  MProfileEngine* profileEngine = CreateProfileEngineL();
  //CleanupReleasePushL( *profileEngine );  
  MProfile* profile = profileEngine->ActiveProfileL();
  //CleanupReleasePushL( *profile );
  
  ret=profileEngine->ActiveProfileId();
  MProfileName const &name = profile->ProfileName();
  
  //CleanupStack::PopAndDestroy(1); // profileEngine
  profileEngine->Release();
  return Py_BuildValue("(iu#u#)",name.Id(),(name.ShortName()).Ptr(),(name.ShortName()).Length(),(name.Name()).Ptr(), (name.Name()).Length() );
}

I'm not familiar with the s60 c++ libs, maybe someone here can spot the problem?

[gaba88]

hi oxidative
first of all a warm welcome to the python dibo. and i hoe you get the best help here.
i think the problem is with the infinite loop that you are using and not with the extension.
have a feedback.

[oxidative]

Thanks for the welcome, gaba88. I used the loop to make the problem visible. In my real script, I have a timer that calls xprofile.get_ap() once every minute. That way it takes about 8 hours before I get the error, but nevertheless it eats up memory although it shouldn't.

[gaba88]

Thanks for the welcome, gaba88. I used the loop to make the problem visible. In my real script, I have a timer that calls xprofile.get_ap() once every minute. That way it takes about 8 hours before I get the error, but nevertheless it eats up memory although it shouldn't.

hi oxidative again
then i can say that you are bit correct but its a assumption not confirmation as i am not so strong in Symbian its better if you write a mail to cyke64 he is the best person to answer as he created this extension.
or try another thing i.e. instead of printing the amount of ram do something simple then check if the same error is there or not.
waiting for feeback.

[JOM]

using the xprofile extension to get the currently active profile.

Strange implementation, SDK docs seem to recommend using Central Repository to get this info? xprofile uses ProfileEngine for some reason. I would experiment re-writing this for CentRep, which requires no capabilities to use.

// WORKS !
static PyObject* xprofile_get_apx(PyObject* /*self*/, PyObject* /*args*/)
{
  TInt ret;
  
  MProfileEngine* profileEngine = CreateProfileEngineL();
  //CleanupReleasePushL( *profileEngine );  
  MProfile* profile = profileEngine->ActiveProfileL();
  //CleanupReleasePushL( *profile );
  
  ret=profileEngine->ActiveProfileId();
  MProfileName const &name = profile->ProfileName();
  
  //CleanupStack::PopAndDestroy(1); // profileEngine
  profileEngine->Release();
  return Py_BuildValue("(iu#u#)",name.Id(),(name.ShortName()).Ptr(),(name.ShortName()).Length(),(name.Name()).Ptr(), (name.Name()).Length() );
}

When looking at the code, it does look suspicious. CleanupStack code is removed on purpose? What if ActiveProfileL() leaves, then how will profileEngine be released? Will Release() also release memory allocated for pointers? What's the purpose of ret variable? Cannot comment whether returning pointers is as bad as it looks, hopefully not.

Possible memory leaks, some expert should definitely review this code.

Cheers,

--jouni

[oxidative]

Strange implementation, SDK docs seem to recommend using Central Repository to get this info? xprofile uses ProfileEngine for some reason. I would experiment re-writing this for CentRep, which requires no capabilities to use.

I'm new to this, but the xprofile extension looked promising. It uses some addon APIs released by nokia. My impression of the Central Repository related solution was that it's more a "hack" than a clean solution. Besides that I also want to change the profile, not only read it.

When looking at the code, it does look suspicious. CleanupStack code is removed on purpose? What if ActiveProfileL() leaves, then how will profileEngine be released? Will Release() also release memory allocated for pointers? What's the purpose of ret variable? Cannot comment whether returning pointers is as bad as it looks, hopefully not.

Looks like there are several ways to "cleanup". Calling Release() should do the trick, however the pointer to MProfile never never gets released. So I've added profile->Release() to it. But now the app crashes right way... the release calls are too early, we still access the pointers in the return statement.

I think I got this baby working, no more leaking so far. This is what I got:

static PyObject* get_activeprofile(PyObject* /*self*/, PyObject* /*args*/)
{
	MProfileEngine* profileEngine = CreateProfileEngineL();
	MProfile* profile = profileEngine->ActiveProfileL();

	MProfileName const &name = profile->ProfileName();
	PyObject *arglist = Py_BuildValue("(iu#u#)",name.Id(),(name.ShortName()).Ptr(),(name.ShortName()).Length(),(name.Name()).Ptr(), (name.Name()).Length() );

	profileEngine->Release();
	profile->Release();
	return arglist;
}

[JOM]

I think I got this baby working, no more leaking so far. This is what I got:

Great! When it's working, maybe you could make a public release for others, too? Not sure how, but I'm positive you'll find out a way

static PyObject* get_activeprofile(PyObject* /*self*/, PyObject* /*args*/)
{
	MProfileEngine* profileEngine = CreateProfileEngineL();
	MProfile* profile = profileEngine->ActiveProfileL();
        ...
}

Line 1 allocates memory for a local pointer. If line 2 fails and ActiveProfileL() actually Leaves, then mempory for 1st pointer is never released. The solution is to use CleanupStack.

Cheers,

--jouni

[cyke64]

Great! When it's working, maybe you could make a public release for others, too? Not sure how, but I'm positive you'll find out a way



Line 1 allocates memory for a local pointer. If line 2 fails and ActiveProfileL() actually Leaves, then mempory for 1st pointer is never released. The solution is to use CleanupStack.

Cheers,

--jouni

Thanks Oxydativ for fixing this bug :-) I'll release soon a new version of xprofile !

BR
Cyke64

[croozeus]

Thanks Oxydativ for fixing this bug :-) I'll release soon a new version of xprofile !

BR
Cyke64

Great! Hope to have the new release, Bug fixed released , soon !

Best Regards
Pankaj Nathani