|
|
-How to Track CTrapCleanup* pCleanup when the thread crashes??-
| Fri, 2007-12-14 12:36 | |
|
Assume that more than one threads are running .. threadFunction() now suppose the child thread crashes in in threadMainL().. I used RUnderTraker to catch the panic/crash but unable to handle the memory leak caused by Can some body help me giving the solution for handling the memory leak in the above/following caes. Code example. TInt leaveCode(KErrNone); /* following line of code will not be called as the thread crashed in threadMainL() it creates a return leaveCode; |
|
Forum posts: 95
The best solution would be to find and fix the reason for panic. A panic/crash indicates programming error (which is not acceptible). Debug your code and find the reason for Panic and fix it.
Chao,
Raghav
Forum posts: 26
CActiveScheduler::Start
and to avoid problems read : http://www.newlc.com/topic-13580 - Number 8
Forum posts: 1134
He doesn't get a panic, he gets a leave.
And leaves are part of the normal error handling, and could happen at any time, most commonly because of OutOfMemory.
You as a programmer is responsible to make sure that your app can handle _any_ leave at _any_point_.
This was an interesting question, I hadn't thought about it. I guess I was thinking that CTrapCleanup would handle this itself. (like save a pointer to itself so it can clean itself up in case of leave.)
Usually it is not a problem too, since the thread will die soon after and free up any heaps and such allocated.
It would be a problem though in the case of shareing heap with the main thread.
Don't have a sollution to it right now... will think about it
Forum posts: 28
>>TInt leaveCode(KErrNone);
>>TRAP(leaveCode, threadMainL(aPtr)); // some ashynchronous service call
>>/* following line of code will not be called as the thread crashed in threadMainL() it creates a memory leak */
is it necessary for us to worry about that?
SymbianLN
Forum posts: 1134
Oops..
Disregard some of my old post, I was a bit confused then it seems
The TRAPD is what makes this work, since it is to the line with TRAPD that the system will jump in case of a leave, and unwind the cleanupstack.
The line after _will_ be run if everything works as it should in a leave, and somewhere below it you delete the cleanupstack.
And it seems I read too quickly... he says it actually does crash in there, as in a panic, and if so, then yes, he should fix the panic.
SymbianLN:
I can only see one case where you might need to worry about it; you can create a thread that uses the same heap as the parent thread.
How will it clean up any allocations done on that heap by the child thread, will it? (I don't know)
I guess it could mark every allocation with a thread ID and go through it and clean it after the thread has died, but it seems a bit cumbersome...
And I guess the official policy is "Thou shall not panic", so it isn't a problem...
Forum posts: 95
Alh,
I don't think your assumption is correct
If "threadMainL" leaves, the program will not close, since it is within "TRAP" the program will continue with following instructions.
Chao,
Raghav
Forum posts: 1134
please read my next post also
Forum posts: 28
>>raghav_an
>>If "threadMainL" leaves, the program will not close, since it is within "TRAP" the program will continue with following instructions.
??I agree with that.
>>I can only see one case where you might need to worry about it; you can create a thread that uses the same heap as the parent thread.
? I will try about it ( but busy now,,,,,,,)
SymbianLN
Forum posts: 4
Any way thanks for the replies ..
I would like to add few more informations here..
>>TInt leaveCode(KErrNone);
>>TRAP(leaveCode, threadMainL(aPtr)); // some ashynchronous service call
>>/* following line of code will not be called as the thread crashed in threadMainL() it creates a memory leak */
Crash here is not a leave or exception its a system Panic ..
code is safe when the threadMainL leaves or result in an exception (exception can be cought by exception handler).
When the system panics that thread dies andRunL is called for the RUnderTraker implementation giving all the reasons and all.
But however we share the same heap/new heap in the thread i am getting memory leak/unable to come out safely from my application.
Forum posts: 4
in addition to the above comment..
we dont have control over the service we are accesing the threadmainL() and that service itself is crashing
So we cant acess the code for the service and fix it..that is foreign to us.we are just trying to use the service.
Forum posts: 95
Isn't it better to not to use the buggy-service
.
BTW what will be the gain of using that service?
What is the necessity of using it? 
Chao,
Raghav
Forum posts: 1134
You can't always chose what services you have to use.
You can also not know if a service is buggy or not in this or that particular release.
Also, there exists APIs that per design might panic you (I don't like it, but its a fact), and you have to handle also these cases if your program should be complete.
Forum posts: 95
Agreed, but what is the gain in accessing such a service. IMHO if the bug is in the service provider it should be resolved before releasing it.
A thread will be Panicked to indicate the programming error (is my assumption correct?).
Chao,
Raghav
Forum posts: 1134
A problem is if the service is already released, and shipped in a couple of million phones, and maybe it works fine in most of them...
Not fun when the service is essential to the functionality of your program...
Thats the general idea, but as always, the limit is floating, and not all panics are documented, and sometimes new ones are introduced in new versions (that might still be BC)
I do agree that this is a case that "shouldn't happen", but with some programming experience, you know that specially the cases that "shouldn't happen" are the ones that come and bites you when the deadline is close
Then its nice to have at least some strategy to cope with them.
But yes.... Number one is "Fix the source of panic", always.
I'm just saying there might be cases where you can't
But I agree they shouldn't be that common....