THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/07/2003 at 12:17, xxxxxxxx wrote:
Cinema 4D Version: 8.100
Language(s) : C++ ;
I have created a plugin and everything seems to be working fine but I have a lot of memory leaks. What should I do? I am not sure how to identify where they are when using the debugger.
On 08/07/2003 at 13:02, xxxxxxxx wrote:
If you create an empty file named "c4d_debug.txt" in the working directory, C4D will open its debug console and display memory leaks when you close the program. (Note that the working directory is usually the location of the .cdl file when debugging, not the C4D folder.) Then you could see what it is that leaks.
On 08/07/2003 at 16:49, xxxxxxxx wrote:
Ok I have the c4d_debug window working, but I didn't understand what you meant by that Note. Some examples of leaks shown are:
BaseContainer.c,19 -> 24 Bytes!
ge_container.cp,1209 -> 16 Bytes!
gv_world.cpp,1159 -> 64 Bytes!
PluginLayer.cpp,387 -> 16 Bytes!
Register.cpp,113 -> 160 Bytes!
ge_container.cp,1209 -> 16 Bytes!
none of these are files I have created, so how do I determine how to fix them?
Thanks again! Sorry if this is a stupid question.
On 08/07/2003 at 17:15, xxxxxxxx wrote:
Well, I never use the c4d_debug.txt but I guess those do not show problems in your files but in the files that you are accessing through your classes. So are you allocating a basecontainer, or do you allocate an Xpresso Master?
But I am not sure if this is really the way it works. As I said, I never used it before. But it shouldn´t be too hard too find your memory leaks is it? If you are manually allocating something you should free it yourself manually too. It´s not too hard, depending on your code complexity of course.
On 08/07/2003 at 17:21, xxxxxxxx wrote:
Thanks Samir! I am allocating an array of basecontainers and a filename in the class. I don't have to worry about allocations in the class functions do I?
On 08/07/2003 at 17:26, xxxxxxxx wrote:
What do you mean by you are allocating them in the class? Do you mean in the class constructor? Then you have to free them anyway.
Some lines of code would help finding the problem...
On 08/07/2003 at 18:08, xxxxxxxx wrote:
Ok here is an example of what I meant by in the class. Thanks for your help!
class Dialog : public GeDialog
virtual LONG Message(const BaseContainer &msg, BaseContainer &result);
virtual Bool CreateLayout(void);
virtual Bool Command(long id,const BaseContainer &msg);
virtual void Timer(const BaseContainer& msg);
BaseObject *camera ;
RenderData *rset ;
};typedef struct RC_Set RC_Set;
long cam, set;
On 10/07/2003 at 04:58, xxxxxxxx wrote:
I have the same problem and a equal debug output. So how can I solve this problem?
On 13/07/2003 at 04:07, xxxxxxxx wrote:
I see no allocation that needs to be freed here.
On 13/07/2003 at 10:02, xxxxxxxx wrote:
is just a pointer to a document , you either point it at a document that you create somewhere else or you will need to allocate a document for it.if you allocate this later , youll need to free it for sure.if you point it to another doucment , youll need to free that one (if you made it)
e.g if you later do globaldoc=LoadDocument(blabla) , you will need to free this globaldoc yourself before your plugin exits.
same with all these pointers , if your allocating them somewhere else , you will need to free whatever you put in them.
depending on what your doing , its often usefull to use AutoAlloc , then you dont need to think about allocation.
there a couple of places that you can deallocate within a GeDialog.
you can use :
virtual color=#800080~GeDialog(void); // destructor
virtual void color=#800080DestroyWindow(void); // geeneral cleanup
use these to cleanup when the dialog is destroyed.
On 14/07/2003 at 14:12, xxxxxxxx wrote:
Thanks I will try all of those suggestions!
On 17/07/2003 at 12:36, xxxxxxxx wrote:
I have a lot of memory leaks in ge_container.cpp?
what are the classes that create this leaks? I can't find it out.
On 17/07/2003 at 12:42, xxxxxxxx wrote:
I think what you see in the debug output window are local parts of an object that has not been freed.
so if you dont release a BaseObject , it wont say in debug "BaseObject not freed"
it will spit out lots of lines that are of no use to you at all in finding the leak.
all you know is that something was not released and that you should go find it
On 17/07/2003 at 12:55, xxxxxxxx wrote:
do you have any ideas? Can that be BaseContainer's thats the only think I know that I don't free. But BaseContainers didn't work with Alloc.
On 17/07/2003 at 12:59, xxxxxxxx wrote:
if you do something like
this does not need to be freed
On 18/07/2003 at 03:38, xxxxxxxx wrote:
I have found them all.