NewLC - TRAP/LEAVE leaking S60 winscw - Comments

Re: TRAP/LEAVE leaking S60 winscw

alh — Tue, 30 Dec 2008 10:16:24 +0100

First:
Please note this thread is 2 years old, noone should use the old ecrt0.lib anylonger unless they really have to.
You should use OpenC instead which is a much better implementation of libc.

ragav_an:
I'm not mika, but I have comments...
At first look, your statement looks kindof-right, but there is a couple of small and subtle problems with it that in my opinion makes what you write strange, and in part totally wrong.
Its possible its just in your use of english, but I comment anyhow in case you have misunderstood something...

"If the exe is linking with STDLIB, the user should link his executable against "ecrt0.lib" or a " CTrapCleanup" pointer should be provided."

1. "provide a CTrapCleanup pointer" is a bit weird way to say it, what you need to do is creating a CTrapCleanup instance, its irrelevant how you manage this instance in your code, but keeping a pointer to it is ofcourse a nice way to be able to destroy it when your app closes (not strictly needed, but makes for clean and nice code)
2. Its not link against ecrt0.lib "or" create ctrapcleanup, you have to do _both_
3. again, this is an obsolete lib that shouldn't be used at all...

Re: TRAP/LEAVE leaking S60 winscw

raghav_an — Mon, 29 Dec 2008 08:13:08 +0100

Hi,

If the exe is linking with STDLIB, the user should link his executable against "ecrt0.lib" or a " CTrapCleanup" pointer should be provided.
If the program is a UI application then the "CTrapCleanup" pointer will be provided by the framework.

Mika, any comments or corrections regarding this.

Re: TRAP/LEAVE leaking S60 winscw

siblex — Mon, 22 Dec 2008 02:23:09 +0100

Maybe it's the CleanupStack's problem..

Re: TRAP/LEAVE leaking S60 winscw

iothal — Tue, 12 Dec 2006 10:40:08 +0100

Actually, without CloseSTDLIB I get a CONE 36.
So I need both ClostSTDLIB && _DisposeAllThreadData
for it to work correctly.
Also with a dummy trap in the main app during construction.
At least now I can continue to see my own leaks and nothing else,
again - thanks Mika.

Re: TRAP/LEAVE leaking S60 winscw

mikaraento — Mon, 11 Dec 2006 20:41:58 +0100

alh: thanks for jumping in. I've now dug deeper into it, and it seems that the problem only (or at least mainly) occurs if you are linking with ESTLIB.LIB.

So _DisposeAllThreadData is the new CloseSTDLIB...?

iothal: the thread allocation functions are defined in the CodeWarrior runtime code, to be found in Symbian_Support\MSL\MSL_C\MSL_Win32\Src\ in the CodeWarrior directory.

I still assume there is a 'correct' way of doing this somewhere.

Re: TRAP/LEAVE leaking S60 winscw

alh — Mon, 11 Dec 2006 16:32:49 +0100

I wonder why I have never run into this.

I have developed servers for 9.1 and 9.2, useing CodeWarrior, and my entry function typically looks like this:

Code:

TInt ServerStartup::RunServer(TAny* aParam)
{
__UHEAP_MARK;
CTrapCleanup* cleanup = CTrapCleanup::New();
TInt ret = KErrNoMemory;
if (cleanup)
{
TRAP(ret, ServerStartup::RunServerL());
delete cleanup;
}
__UHEAP_MARKEND;
return ret;
}

I have never got any false memory leaks with this code...

I would like to know a bit more about when this occours for you...
Is it only in emulator build? only on target build? both?

Is it only if you use User::__DbgMarkCheck, but as above when you use only MarkEnd you don't get the problem? (MarkEnd also gives the alloc fail panic)

I use RVCT for target builds and build that from command line.. Only build to emulator from within codewarrior.

But I've never seen this problem, even in emulator build, but it worries me some... would like to understand it before I run into it a week before some major release

Could you explain it a bit further mika?

Re: TRAP/LEAVE leaking S60 winscw

iothal — Mon, 11 Dec 2006 15:19:58 +0100

Thanks again Mika, it works like a charm now!
Where did you find _DisposeAllThreadData btw, just curious...

Re: TRAP/LEAVE leaking S60 winscw

mikaraento — Mon, 11 Dec 2006 11:27:49 +0100

I have the feeling this is not the way it's supposed to be done, but anyway, here's a fix. Add a declaration

Code:

#if defined(__WINS__) && defined(EKA2)
extern "C" {
void _DisposeAllThreadData();
}
#endif

and a call to a suitable location, like:

Code:

CSymbianOSUnitApplication::~CSymbianOSUnitApplication()
{
#if defined(__WINS__) && defined(EKA2)
_DisposeAllThreadData();
#endif
}

Dlls that do not already have a clear tear-down function, the situation is more problematic.

Re: TRAP/LEAVE leaking S60 winscw

iothal — Sun, 10 Dec 2006 15:09:28 +0100

Thank you very much Mika!
And yes, these things should be documented for sure!

Re: TRAP/LEAVE leaking S60 winscw

mikaraento — Sat, 09 Dec 2006 14:57:37 +0100

You are correct, TRAP/Leave does leak on Codewarrior with Symbian OS 9.1.

On 9.1 TRAP/Leave are implemented with try/catch/throw. The Codewarrior implementation of c++ exceptions needs to allocate some support structures in thread local storage. These are allocated on the first use of TRAP/Leave.

The only solution is to have a dummy TRAP(err, User::Leave(1)); outside the leak tracking.

The stupid thing is that it seems that the support structures are at least sometimes allocated per module. So you actually need to have such a dummy TRAP exported from all the dlls you create, and call them before leak tracking.

This does not seem to be a problem for platform modules. I don't know why. Guesses:

The platform dlls are not using try/catch/throw
They force allocation of the thread local structures on load
They are compiled with a different set of runtime libraries or a modified compiler

Neither do you run across it with apps, where the framework does the tracking.

Don't you wish they'd document these things?

Re: TRAP/LEAVE leaking S60 winscw

NumptyAlert — Fri, 08 Dec 2006 20:53:37 +0100

Its interesting that this code runs as there isn't a trap cleanup object created.

Try this and see if you still have a leak:

void PushLotsL()
   {
   TInt* dummy = NULL;
   for (TInt i = 0; i < 100; i++)
      {
      CleanupStack::PushL(dummy);
      }
   CleanupStack::Pop(100);
   }

TInt E32Main()
   {
   static CTrapCleanup* TrapCleanup = CTrapCleanup::New();
PushLotsL();
   remainder of your code

P.S.
Why are you calling the User functions directly and not using __UHEAP_MARK etc.?

Re: TRAP/LEAVE leaking S60 winscw

srikanth — Fri, 08 Dec 2006 11:49:46 +0100

Sorry for that.

According to me Yes, you are right. It should never fail. Its very strange that it says a memory leak.

Cheers,
Sri

Re: TRAP/LEAVE leaking S60 winscw

iothal — Fri, 08 Dec 2006 11:41:08 +0100

Look at the code, it doesn't allocate anything.
It calls User::Leave and nothing else.

cheers m8

Re: TRAP/LEAVE leaking S60 winscw

srikanth — Fri, 08 Dec 2006 11:39:26 +0100

Wrong.

Memory leaks can still there even if you use TRAP untill and unless you dont push the dynamic objects in to cleanup stack. This is especially required if you are calling any leaving functions after allocating memory for any dynamic objects.

Cheers,
Sri

TRAP/LEAVE leaking S60 winscw

iothal — Fri, 08 Dec 2006 11:21:32 +0100