Arvindtn
asked on
Handling abnormal program termination
Dear Friends,
This is my problem, I have written a COM DLL which creates a very complex link list. I have handled all errors inside the COM DLL and i also clear the Heap asap.
The average number of nodes in the link list will be about 10,000 to 15,000 nodes.
The program which uses this COM dll may not handle the exceptions (Client can be in Visual Basic, C++ or Visual C++), Now if the program that uses this COM dll terminates abnormally then how can i release all the memory allocated by the COM dll in the heap?
Is there any way i could handle this, because since it creates about 10,000 to 15,000 nodes, the memory usage is bit high and i want to free the heap even in case of abnormal termination.
Thank you in advance
Arvind T.N
This is my problem, I have written a COM DLL which creates a very complex link list. I have handled all errors inside the COM DLL and i also clear the Heap asap.
The average number of nodes in the link list will be about 10,000 to 15,000 nodes.
The program which uses this COM dll may not handle the exceptions (Client can be in Visual Basic, C++ or Visual C++), Now if the program that uses this COM dll terminates abnormally then how can i release all the memory allocated by the COM dll in the heap?
Is there any way i could handle this, because since it creates about 10,000 to 15,000 nodes, the memory usage is bit high and i want to free the heap even in case of abnormal termination.
Thank you in advance
Arvind T.N
ASKER
Yes, the memory in the heap is not cleared, I think the OS will clear only the stack of the client process. Some times to clean up the memory the client needs to have a restart.
Is there any way in which the DLL could trap the abnormal termination?
Is there any way in which the DLL could trap the abnormal termination?
You have to differenciate beteen memory leaks and thrown exception.
The latter is easy. Use a try catch inside every STDMETHOD implementation and translate all errors into HRESULTs.
There's no cure for memory leaks aside from:
1. Writing good code.
2. Using process isolation (i.e. an EXE COM server)
The latter is easy. Use a try catch inside every STDMETHOD implementation and translate all errors into HRESULTs.
There's no cure for memory leaks aside from:
1. Writing good code.
2. Using process isolation (i.e. an EXE COM server)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I will explain my problem more clearly.
iam using inproc server dll in a Visual Basic Standard EXE. The VB Server connects to a Socket and starts to receive messages, These messages are used to create a complex Link List. The size of the Link List is about 10,000 to 15,000 nodes, thus using abt 1 to 3MB of memory.
Now if the VB program terminates abnormally how will i clear this 1 To 3MB of memory allocated to the inproc Dll through the 2new operator", under normal cirumstances, the memory can be cleared either by destroying the object (using delete operator) or by calling a COM Method.
If the VB program terminates abnormally, will the OS clear the heap of the Inproc DLL?
If not then how can i do this?
Regarding the Unhandled exceptions, where should i write it, in the Inproc DLL or in the Server?
I can solve the problem by handling the exceptions in the Program which utilizes the Inproc DLL, but if the Inproc DLL is used by some other program, then there is a possibility of abnormal termination.
The abnormal termination can be due to unstructured error handling in the Program that uses my Inproc DLL, In this case how can i free the memory in the heap, though the error was not raised from the Inproc Dll but from the program that uses the Inproc DLL?
iam using inproc server dll in a Visual Basic Standard EXE. The VB Server connects to a Socket and starts to receive messages, These messages are used to create a complex Link List. The size of the Link List is about 10,000 to 15,000 nodes, thus using abt 1 to 3MB of memory.
Now if the VB program terminates abnormally how will i clear this 1 To 3MB of memory allocated to the inproc Dll through the 2new operator", under normal cirumstances, the memory can be cleared either by destroying the object (using delete operator) or by calling a COM Method.
If the VB program terminates abnormally, will the OS clear the heap of the Inproc DLL?
If not then how can i do this?
Regarding the Unhandled exceptions, where should i write it, in the Inproc DLL or in the Server?
I can solve the problem by handling the exceptions in the Program which utilizes the Inproc DLL, but if the Inproc DLL is used by some other program, then there is a possibility of abnormal termination.
The abnormal termination can be due to unstructured error handling in the Program that uses my Inproc DLL, In this case how can i free the memory in the heap, though the error was not raised from the Inproc Dll but from the program that uses the Inproc DLL?
>>If the VB program terminates abnormally, will the OS
>>clear the heap of the Inproc DLL?
Yes, it will, even though it's good practise to do that by yourself.
>>Regarding the Unhandled exceptions, where should i write
>>it, in the Inproc DLL or in the Server?
In the inproc DLL - BTW, regarding terminology: The DLL is an inproc COM server, so it's actually the same...
>>clear the heap of the Inproc DLL?
Yes, it will, even though it's good practise to do that by yourself.
>>Regarding the Unhandled exceptions, where should i write
>>it, in the Inproc DLL or in the Server?
In the inproc DLL - BTW, regarding terminology: The DLL is an inproc COM server, so it's actually the same...
ASKER
Iam now implementing the 'SetUnhandledExceptionFilt er' in my Inproc DLL, will get back soon
what about putting the clean up code in the DLLMain function, put it in the case statement that gets called when a process is finished with the dll, perhaps this is called regardless of the type of program termination.
i dont know if that will work, its just a thought
Paul
i dont know if that will work, its just a thought
Paul
-- Dan