Sat, 11/22/2003 - 00:55
Forums:
I am trying to create a application based on OPEN CASCADE and for that, I start from the samples and modify them.
When the native samples (without any modification) are executed in debug mode and with the debug DLLs one can see many memory leaks. This occurs also if no nothing is done (just launching and exiting). As all the samples are based on mfcsample.dll, I presume something is wrong in the code of this DLL. Does somebody have an idea ?
Thank you for your help.
Mon, 11/24/2003 - 11:46
Hi !
Just because the application complains does not mean that you have memory leaks, if you for example allocate a buffer when an application is started and then reuse it until the application ends, if you don't free this buffer when the application terminates you will get a message about memory leaks, even though there are none, ok, it is good practice to delete any allocated memory when you terminate an application, but not doing so is not an error.
You also have to remember that OCC use a "garbage collector", it has reference counters on many objects, so they can be deleted when they are no longer needed, that's why you don't use "delete" on most of OCC created objects.
Check out the pdf files, there are some pretty ok descriptions on how this works.
Mikael
Mon, 11/24/2003 - 13:54
Dear MiKael,
Thank you very much for your reply. I have already read the principle of memory management of OCC, with the counters. I am ok to say that the memory leaks message are perhaps not errors if
delete is not called at the end... but I have a serious doubt when I see the THOUSANDS of memory leaks lines that are output !
The problem, if the memory is not released before the program exit, is that you are unable to do the difference beetween "normal" memory leaks and "abnormal" memory leaks because of a bad counter management or undelete objetcs. In the case of OCC, I am convinced that most of memory leaks are not normal and have to be corrected. How?
Mon, 11/24/2003 - 14:27
I have not used OCC 5 so I don't know what kind of memory leaks you get, it is possible that they are true memory leaks, I don't know.
And I am sorry to say, but you are probably not going to find any answer to it either unless some OCC user knows more about it, don't expect to get an answer from the OCC developer folks, they only answer if you have payed money for OCC or they think you you might be interested in buying OCC.
The ones that only download OCC (for free) is expected to help improving OCC so they can make more money on it, we should not expect to receive any help from them, they have made that pretty clear in the past.
Mikael
Mon, 11/24/2003 - 23:38
Thank you again Mikael, your information is precious because it probably means that this version (5.1) I have just dowloaded has many memory problems but that it is not the case with the previous version you use.
I have here also the 4.0. Can you tell me if (as far as you know) this version is OK in term of memory management.
Tue, 11/25/2003 - 02:20
Hello Bernard,
I agree with Mikael that this is not the numerous messages that Visual Studio print that indicates a real memory leak in OCC.
What makes you convinced that there are memory leaks in OCC. Maybe there are, but do you have serious clues (except the output from Visual Studio) ?
For my experience I can tell you two places in OpenCascade where memory is reused without being freed :
1/ in OpenGl package which is responsible of the low-level routines to manage 3D graphic display. There are C structures which are allocated the first time you display something using OpenGl.
These structures are not freed since the only moment when you stop using OpenGl is when you terminate the application (most of the time). If in the Visual Studio debug windows you see some strange ascii data (like "tata") that complains to be not freed, then it corresponds to such structures.
2/ And finally OCC has its own memory management allocator. In particular this memory management have some kind of pool for allocations of small objects. So even when objects are finalizing their scope (by calling their destructor) the memory zone will not be freed but instead being reused (as far as it cans) for another future object.
In conclusion, the real leak in OCC is that it is very difficult to detect real memory leaks (in OCC or in your own application using OCC). Even if you use some specific tools like Purify, these tools will report you a lot of suspicious data, and the work to filter the real memory leaks can only be a hard human work.
One suggestion to OpenCascade team (of to another courageaous contributor) is to provide some basic memory analysis tools. Because most of objects manipulated by Handle can be counted, and internal memory pool can counts at least the number of allocation/free pair by size for example. I remember some hidden environment variable in OCC memory manager that was useful to output some kinds of such counters anywhere in your program. But it seems that the implementation is somehow broken or incomplete at least in versions 3.0 and 4.0
Regards
Tue, 11/25/2003 - 14:16
Hi Jeanmi,
I agree with you that the number of visual studio memory leaks message is not a proof of memory leaks inside OCC. At this level, it is a serious doubt, but not more !
I tried to make a small function that reads an IGES file and then try to sew the faces to create a shell. This function is included inside an infinite loop to be able to see the windows memory manager evolution. Once the object(s) is returned by the function, it is deleted before starting the next loop. Sometimes (but not always), depending on the IGES file I read and the treatment done on the read entities, I can see the memory used that continuously encreases (ie true memory leaks).
The problem when I see memory encreasing continuously is to know who is responsible of the problem ? the function of OCC I use (and in this case I have to debug OCC or to choose an other development platform) or the way I use the OCC function, and in this case I have to debug my part (which more simple), but how ?
Usualy the memory leaks messages are a good way to do this debug because when you have no message, you have the certainty that your program is OK. Here, it is just a feeling and it is not satisfying.
Thank you again for all.
Bernard.
Mon, 12/01/2003 - 16:03
Hello Bernard,
as you might know, Open CASCADE implements its own memory management mechanism adapted to the particular needs
of the classes which use it. Our experience shows that sometimes behavior of the memory management may not be quite understandable by the end users, partially due to its complexity, partially due to lack of documentation.
It seems to us that, in addition to the improvements in documentation, we could think of creating some sort of FAQ
for such type of subjects. In this message, I just give some brief recommendations.
In order to isolate memory leaks in the program based on Open Cascade, I recommend you to use Rational Purify (licensed tool of IBM Rational Software) instead of VC++ embedded tools. It gives much more help, because it makes exhaustive analysis of all allocated memory blocks and reports only those to which no pointer exists anywhere in the application space. In addition, it reports the stack of the application at the moment of allocation of each leaked block.
But even in this case great amount of memory is false detected and reported as leaked. For that there is a simple reason: some OCC functions do not store/return the pointer to the original block that malloc returns, but rather add or subtract an offset value and store/return the result of offset. In
this case really there is no leak, because there is an opposite action before releasing memory: the same offset is subtracted/added from a pointer. But Purify reports all blocks allocated (and not yet freed) by these functions. For example, such behavior is implemented in the functions
Standard::MAllocate and Standard::MFree, in the generic classes TCollection_Array1 and TCollection_Array2, in the functions cmn_getmem and cmn_freemem in the package OpenGl.
In order to reduce the number of false detected leaks you can set the environment variable MMGT_OPT to 0 before OCC application launch. It switches off optimization code in OCC allocator (package Standard) so that the allocator returns exactly the same pointer that returns malloc.
Using the filtering technique provided by Purify, it is easy to filter out messages concerning Arrays and OpenGl.
Some efforts were done internally in OCC to eliminate memory leaks in the toolkits TKernel and TKCDF using the described technique. Several real leaks were found in TCollection strings and in LDOM package, and the patch comes with the last OCC maintenance release which is available for our customers only. All other users may expect it to appear in the following public version of Open CASCADE.
With best regards,
Forum Supervisor
Fri, 12/05/2003 - 11:01
Hi Supervisor,
Excuse me for the delay of my answer, I was out these last days. I wanted to thank you for your explanations. Even if it does not give me "the" solution, it gives me some track to explore !
Thank you again.