CActive object destructor not called

[marmirman]

Hello,

I've a class derivating from CActive object (first time I do that), when I launch an instance of this task, all is good, but after the last RunL call its destructor is not called, and so at the application destruction, there is memory not free corresponding to this object.

And at the end of the last RunL, iActive is false, and iStatus is -1 (Test done in error case, CActive object on normal fct need gprs to run, i can't debug it: it seems to be too complex to make internet works on emulation)

Normally, I don't have to delete my task in the last RunL call, no ? What could lock the CActive object ?

An other question In many cases displaying dialog boxes in RunL causes application to hang or in one case paint problem on dialog boxes, does it be "normal": dialog boxes use forbidden in RunL ? or does it be caused by others problems ?

Thanks by advance for help

[pavanmv]

Hi,

The dtor is not called automatically so you need to call delete on the AO,
No there is nothing that can prevent the destruction of the AO, even if there is a request pending it can be destructed.
and also check if the destructor has been defined properly. Do call cancel() as the first statment in the dtor.
I know the answer may sound silly but please so check coz we do sometimes make some silly mistakes.

[marmirman]

[...]we do sometimes make some silly mistakes.

It's clear

So at the end of my RunL i have done that:
if (!IsActive())
//assuming that SetActive set IsActive() return to true
{
Deque(); //maybe not necessary ?
delete this;
}
Is it correct ?

And it seems to work, dtor is called and no more memory leak.

Thanks for your response.

But for dialog boxes, does it be normal to have problem using them when called from RunL (ex: iEikonEnv->InfoWinL) ?

[david.caabeiro]

delete this is ok but you should be very careful not to call any other member function / data after it. As a rule of thumb, don't call anything else after "commiting suicide"

Also, beware of other pointers referring to that object, double deletion, etc.

In most cases, the AO (as any object as well) should be deleted by the object that instantiated it.. give a second thought to your design.

[marmirman]

[...] "commiting suicide"

I love your expression

In most cases, the AO (as any object as well) should be deleted by the object that instantiated it.. give a second thought to your design.

Im a multithreaded dev addict (on other platform), so i ll do many of my devs to be concurrent, but here it s a little game and for the particular fct which use async objects, running more than one time at the same time has no sense and finally was a problem ... So I have followed your directives.

So now on phone all works fine(launching x time my synchro function without problem,each new request destroying the previous) until I close application (On emulation no problem but sockets are not usable), the application hang and one time I have seen a kernel-Exec 3 error (unhandled exception)...

Maybe it is linked to the fact I can't display dialog boxes from CActive::RunL after first socket successfull operation, and same thing happens after socket was shutdown and properly closed. Reentrance problem for dialog boxes? or...

But maybe it should better to open an other thread for that?

[marmirman]

COOOOL! My problem is solved...
All stranges behaviours (dialog not displayed or half painted, draw problem, application not responding at close) was due to the fact I use User::WaitForRequest((CActive.)iStatus) in cactive RunL... in two "little" case.
No where I see that this function (on cactive.iStatus only maybe?) should be NEVER use in an active object except here:

http://newlc.com/Common-mis-use-and-abuse-of.html
A good paper wrote by a guy a little too hard... giving no explanation but what we should not do :

2. Calling WaitForRequest in an ActiveObject
People putting calls to User::WaitForRequest(iStatus) in an active object.

If you do this you deserve all the pain and hours of debugging and your code not working you will get as a consequence. Go and RTFM. This is very wrong. Why are you doing this? - you'll never see this in a book, in an SDK, in example/tutorial code. So therefore why are you doing it?

(note that calling WaitForRequest in an active object is possible, but not using the iStatus data member, see below).

3. Overriding the TRequestStatus data member of an ActiveObject
People declaring an additional TRequestStatus in an active object then using that instead of iStatus in combination [1] with SetActive().

Don't declare an additional TRequestStatus in an active object, CActive already has one, you should use that.

I'have just seen a lot of code example on the web which make call to WaitForReq on RunL implementation, example I have taken to write my async requester is one of them... lol
I have not seen in symbian doc that waitForReq should not be called from runl... but my doc version is a little old (2004... glups). But If I should make only what is given on tuto, samples or doc I would do a little more than nothing...
And finally point 2 and 3 seem to be a little audi... 2->dont use iStatus for waitForReq, use another. 3 -> dont declare an other, use iStatus... I'm lost, explanations are too short.

But thanks anyway to the guy who wrote that, without him I would be searching my problem again and for a long time.

Does any one has more precision on this restriction?

I understand that WaitForRequest make reentrance by continuing the job of activescheduler and others os/app tasks and events of the thread, like windows platform with messages queues. But I dont understand why reentrance doesn't work (finally with sockets... for dialogs after waitforreq correcs and after sockets are closed, they are now displayed from runl without pb, and this is a case of reentrance which seems to work).

[pavanmv]

Another tip here on active objects.

It is not really required for you to call the Deque() if you are calling Cancel()
It is a really good practive to call Cancel() as the first statement in the dtor of the active object. Please note that Cancel() in turn always calls Deque() so if we do not call it explicitly but do call Cancel() that should do the job.