TRAP/LEAVE leaking S60 winscw
| Fri, 2006-12-08 11:21 | |
|
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? |
|






Forum posts: 285
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
Forum posts: 11
It calls User::Leave and nothing else.
cheers m8
Forum posts: 285
According to me Yes, you are right. It should never fail. Its very strange that it says a memory leak.
Cheers,
Sri
Forum posts: 194
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.?
Forum posts: 30
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:
Neither do you run across it with apps, where the framework does the tracking.
Don't you wish they'd document these things?
Forum posts: 11
And yes, these things should be documented for sure!
Forum posts: 30
extern "C" {
void _DisposeAllThreadData();
}
#endif
and a call to a suitable location, like:
{
#if defined(__WINS__) && defined(EKA2)
_DisposeAllThreadData();
#endif
}
Dlls that do not already have a clear tear-down function, the situation is more problematic.
Forum posts: 11
Where did you find _DisposeAllThreadData btw, just curious...
Forum posts: 1156
I have developed servers for 9.1 and 9.2, useing CodeWarrior, and my entry function typically looks like this:
{
__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?
Forum posts: 30
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.
Forum posts: 11
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.