Mon, 05/30/2011 - 09:38
Today I see what's occ's today.
I just changed from occ release dll to debug dll. - beofore I just use release to compile rapidly
what I cound see is a lot of mess - that's the memory leaks.
what's going on!!!
Find it! Find it!.
I belived in OCC's reliability.
I thought it's my fault.
more and more I got what I found is the bug.
a lot of bug is that declearation of dll export but it have inline body in lib as well.
that make so many bugs, in debuging I was deleting my source and following occ's bug.
eventually I'd deleted all of my soureces unless one line of occ code.
just it is
TopoDS_Shape aShape;
At least It is like a Auto pointer.
it have to be ereased when it's out of stack.
but it's remained. and remains forever.
it'was not connected with any orther builder or Tshape. It is just one line declartaion.
I am frustrated and disapointed at this lib
It is just free lib and if you want to use it commercially then you have to do more efforts.
Mon, 05/30/2011 - 09:44
mything:
Before shouting that loud, can you be more specific about what kind of errors you see and how you observe them ?
Let me assure that the following app:
int main (int argc, char* argv[])
{
TopoDS_Shape aShape;
return 0;
}
does not provoke memory leaks.
Thanks,
Roman
Mon, 05/30/2011 - 09:47
I repeat my post one more time.
This topic has been already discussed many times. Please, use the search.
The short answer: you can switch off using internal memory manager setting environment variable MMGT_OPT=0.
Mon, 05/30/2011 - 10:17
Hello,
Could you provide a short sample to reproduce the problem?
Thanks
Mon, 05/30/2011 - 13:25
there is a 99.99% chance that there is no problem, of the description it does sound like he got a bunch of messages about unreleased memory blocks, and that is the behaviour of the memory manager so it is no problem, people just assume it is because of the messages.
Mon, 05/30/2011 - 14:38
Hi Roman
your blog is very nice. there was very usefull for me.
anyway here is what you want to see that very basic mfc program
that is made default. and I do just env setting and write one line.
but, not TopoDS_Shape because Bearloga is missunderstandin me
that he thought I do not what\'s memory pool so it can not be erased immediately
but I know what is memory pool very well
so the line is this #include
just builld attached file then you can see the problem.
Hi mikael.
do you correctly know what\'s bunch of message that about output description.
you know why it descripts this every time. just it\'s not need?
THAT MEANS PROGREAMS MEMORY MEMAGEMENT FAIL,
if it menages well then it\'s easy to erase all memory that it used before it\'s exited.
something losted memory fragment added and make it used in some limited
it not gonna use real time system ( what need it to run continuously)
english is my second language. I can not say what I want in first language,
I think that this time is we allow to recognise the problem.
attached file - checkit.zip
project name: NewTest, vc10 win32, dubug
OCC ver : OCC 6.5.0 - with vc10 dubug build dlls
os : windows 7 64 (WOW mode)
etc : OCC_MEMORY_LEAK.png - for check the problem. see it
Mon, 05/30/2011 - 15:20
mything:
Thanks for providing more details.
Quick reply - this MS tool mainly reports about the static objects that get destroyed upon program termination. These are rather false positives, than true leaks. These static objects live throughout the application lifetime. Their destructors are called during exiting the application.
See for instance GProp_SGProps.gxx - there are multiple static objects which underneath allocate from help, during the program load time. They reside in memory until the program termination and the MS tool report them as leaks.
To work-around that there could be some 'watcher' objects that would destroy all these but the only useful thing these watchers would do would be this clean to make the reporting tool happy.
Bottom line : even if OCC likely does contain some leaks they are not as fatal as can be concerned about. Using handles (Handle_Standard_Transient subclasses) play great help here.
Hope this helps.
Roman
P.S. I once put a placeholder about memory management into FAQ (http://opencascade.wikidot.com/faq) was never up to fill it in to explain in more details. Any volunteer help will be more than appreciated.
Mon, 05/30/2011 - 15:22
typo correction:
... static objects which underneath allocate from *heap* ...
Thu, 06/02/2011 - 13:01
OK. I have finally drafted a blog on this subject. Here is part1.
Hope will be helpful.
Thu, 06/02/2011 - 12:18
Dear mything,
Thank you for the provided sample and your efforts for drawing our attention to the potential problem of memory leaks.
I would like to inform you that we have checked the posted problem and we can confirm that the memory leaks you reported
have "false positive" nature, as it was clearly described by Roman (Separate thanks to Roman for his exhaustive comments).
The fact that the "memory leaks" you discovered are false is also proven by years of industrial testing and using of OCCT in commercial projects.
Using this opportunity, we would like to advise you to be more discreet posting your problems.
Your shouting and false accusations in this thread is not the best example of behavior, really...
Regards
Forum supervisor
Thu, 06/02/2011 - 23:08
superviser
I don't understand why you strongly deny it first.
here is a forum, everybody can say what's wrong. and porve it together.
then I have some porve.
there are very simular things but i select it because very clear.
When you include everywhere in MFC app
You can also see memory leak. (so called false accusation?)
Just check a line Line 59 in Standard_Storable.hxx.
The Line is
Standard_EXPORT virtual ~Standard_Storable(){Delete();}
This line is used dll export as well as inline method body.
Is this line correct in c++ grammer?
It can not have both dll export body and inline method body.
It is so clear for us but the definition is weak
Some interest is what's priority is higher dllexport or inline.
therefor it rely on compiler ,linker, os and more over version of those,
then Check out.
just delete Standard_EXPORT.
the line is
virtual ~Standard_Storable(){Delete();}
we will nomore see the momory leak message whenever we use Standard_Storable.hxx.
but there are so many things somthing like this.
there was some my contribute.
Regards
Mon, 06/06/2011 - 11:36
Dear mything,
Thanks for your permanent efforts in the search of OCCT weaknesses.
We welcome any technical discussions which can benefit to OCCT quality.
Concerning the subject I just can say that personally I am not a fan of this style (mixing Export & inline directives). Nevertheless it doesn't lead to memory leaks.
I checked it with Intel Parallel Inspector ( see the attached picture reporting result).
Resolution ==> No Problems detected. The check was done with set of the maximal level - 4.
From other side the detected by you problems may be result of your own application's errors.
So, to avoid any arbitrary treatment I propose you always attach in the future to the post a testing sample which would allowed easy reproducing of the identified problem by a third party.
Once again thanks for your contribution.
Regards
Forum supervisor