TRAP/LEAVE leaking S60 winscw

Login to reply to this topic.
Fri, 2006-12-08 11:21
Joined: 2005-08-20
Forum posts: 11
Hi guys.

This is probably something trivial but I do not see it and been staring at it for some time now.

This =>

GLDEF_C TInt E32Main()
{
        _LIT8(KFilename,"blaha.txt");
        User::__DbgMarkStart(EFalse);
        TRAPD(perr,User::Leave(KErrAbort));
        User::__DbgMarkCheck(EFalse, EFalse,0, KFilename().Ptr(), __LINE__); // <----
        User::__DbgMarkEnd(EFalse,0);
        return EikStart::RunApplication( NewApplication );
}

fails with Alloc Count 1 for a beastly thing of a bob that I have to maintain,
have anybody seen anything like this before or is this a unique monstrousity?

Fri, 2006-12-08 11:39
Joined: 2004-05-21
Forum posts: 285
Re: TRAP/LEAVE leaking S60 winscw
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
Fri, 2006-12-08 11:41
Joined: 2005-08-20
Forum posts: 11
Re: TRAP/LEAVE leaking S60 winscw
Look at the code, it doesn't allocate anything.
It calls User::Leave and nothing else.

cheers m8
Fri, 2006-12-08 11:49
Joined: 2004-05-21
Forum posts: 285
Re: TRAP/LEAVE leaking S60 winscw
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
Fri, 2006-12-08 20:53
Joined: 2006-03-04
Forum posts: 194
Re: TRAP/LEAVE leaking S60 winscw
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.?
Sat, 2006-12-09 14:57
Forum Nokia Champion
Joined: 2004-08-31
Forum posts: 30
Re: TRAP/LEAVE leaking S60 winscw
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?
Sun, 2006-12-10 15:09
Joined: 2005-08-20
Forum posts: 11
Re: TRAP/LEAVE leaking S60 winscw
Thank you very much Mika!
And yes, these things should be documented for sure! Smiley
Mon, 2006-12-11 11:27
Forum Nokia Champion
Joined: 2004-08-31
Forum posts: 30
Re: TRAP/LEAVE leaking S60 winscw
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.
Mon, 2006-12-11 15:19
Joined: 2005-08-20
Forum posts: 11
Re: TRAP/LEAVE leaking S60 winscw
Thanks again Mika, it works like a charm now! Smiley
Where did you find _DisposeAllThreadData btw, just curious... Wink
Mon, 2006-12-11 16:32
Joined: 2004-11-29
Forum posts: 1156
Re: TRAP/LEAVE leaking S60 winscw
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 Smiley

Could you explain it a bit further mika?
Mon, 2006-12-11 20:41
Forum Nokia Champion
Joined: 2004-08-31
Forum posts: 30
Re: TRAP/LEAVE leaking S60 winscw
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.
Tue, 2006-12-12 10:40
Joined: 2005-08-20
Forum posts: 11
Re: TRAP/LEAVE leaking S60 winscw
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. Smiley
  • Login to reply to this topic.