Memory filling up

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 23/09/2008 at 04:47, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   9.6-11 
Platform:   Windows  ; Mac  ;  Mac OSX  ; 
Language(s) :     C++  ;

---------
Hi,

I have an object plugin that has a big bunch of own data. Ok, everything works fine except for the CopyTo() part. I am copying all the data over to the destination node when CopyTo is called. It´s all working fine however somehow my memory starts to fill up without any reason.

Are there any flags where one should NOT copy over the private data? (although I never had any problems with copyto in the past and it seems copying my data to the destination node is necessary).

Is it the undo buffer maybe? When I delete my object this memory is not freed. I triple checked my code. I am freeing any allocated memory in my destructors (if there is any left).
However, when I close the scene, the memory is freed which tells me that it could be the undo buffer (The debug console also does NOT give me any memory leaks, so it´s somehow related to the scene storing the copied memory somewhere...we are talking about 50MB or more per CopyTo, just as a side note). Any idea what this is all about?

I did some tests and when I don´t copy my data to the destination when the flags are COPY_NO_HIERARCHY and COPY_NO_BRANCHES (which seem the most fitting, though I must admit I don´t fully know what these flags actually mean concerning private data) and then the memory is not filled up! But the destination node does NOT have my private data then, which doesn´t seem correct to me (as it would mean whereever the destination node is used, it needs to rebuild all the data). But I cannot release with this memory filling up as it kills the RAM in several minutes. :-(

I appreciate quick help as this is really essential to me right now.

Thanks in advance for any kind of help to resolve this issue asap.
Samir

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 23/09/2008 at 07:04, xxxxxxxx wrote:

Have you checked how much memory your private data is using? Have you tracked the number of CopyTo calls and what flags are flags send? Anyway I asked the developers about the CopyTo flags because I don't know if some are treated specially.

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 23/09/2008 at 07:11, xxxxxxxx wrote:

Hi Matthias,

it´s dynamic data, it fully depends on the user defined settings. It can be 10KB and it can be 100MB.

As I said, when the flags are NO_BRANCH and NO_HIERARCHY and I don´t copy, everything is fine. No memory fill up. (although the destination node does not have the data then).

The flags are sent when I change an AM setting and when I do an undo, so I concluded that it´s the undo buffer the destination node belongs to.

thanks. Waiting for info from devs.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2008 at 05:53, xxxxxxxx wrote:

Any news on this yet?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2008 at 06:20, xxxxxxxx wrote:

I will post as soon as I have an answer from our developers. One more question, is it always a constant amount of memory that is filling up? Otherwise it could be really just the undo buffer.

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2008 at 07:11, xxxxxxxx wrote:

Nope, it´s dynamic according to my dynamic data. Never the same definetly. It´s that I MUST release tommorrow and there is no way around it. So it´s quite urgent to know if it´s fixable.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2008 at 07:18, xxxxxxxx wrote:

Well in that case it seems to me quite logical that it uses that much memory. I mean if I have an object with lots of polygons it will also fill up quite quickly if I copy it several times. I am sorry that I can not be of much more help here as I have also to wait and see if the developers have something to say about it.

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2008 at 07:28, xxxxxxxx wrote:

Yeah, I know. I am probably a little bit in panic and get impatient. I know you have to wait too.

Well, thanks for your opinion at least. I do some more tests in the meantime. It´s frustrating that activating a bool element will put another 50MB into the undo buffer (I don´t even copy the object, it´s just changing any AM setting will put that memory in RAM, even if that setting will e.g. only change the drawing options of my object).

If it was only the case when I copy my object in OM for example, that would be nice! :)

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2008 at 07:35, xxxxxxxx wrote:

Quote: _It´s frustrating that activating a bool element will put another 50MB into the undo buffer (I don´t even copy the object, it´s just changing any AM setting will put that memory in RAM, even if that setting will e.g. only change the drawing options of my object).
>
> * * *
_

Ok, I see your point. Maybe introduce some checks what has changed in your object, for instance if there was only a change of some parameters that don't affect your private data don't copy it.

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2008 at 07:42, xxxxxxxx wrote:

yep, I am already doing that in combination with those two flags now, however that´s only "a drop on a hot stone" :o/

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 02/10/2008 at 09:06, xxxxxxxx wrote:

Well, I hope I do get an answer BEFORE the support goes on the Roadshow and I don´t have to wait another 3 weeks for an answer that should be answerable (does that word exist at all) within 5 minutes if a programmer would take the time to look this up instead of drinking a coffee (the hell, he can even drink the coffee while looking it up!) *cough* thx

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 02/10/2008 at 09:21, xxxxxxxx wrote:

Copying of the private data should not depend on the flags.We would need some source code that shows the problem. You can also build your own memory managment with reference-counting (protected with semaphores), meaning you link the memory of your private data.

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 02/10/2008 at 09:27, xxxxxxxx wrote:

You need source? ok here is an example that is exactly the same:

myobject
{
private:
   MyData* data;
}

CopyTo()
{
if(dst.data==NULL)
dst.data = gNew MyData(data);
}

That´s all about it, just with a different amount of data. There are also no magic or absurd data types, I use C++ Standards in all my code and C4D SDK Datatypes/typedefs only! No external libs of any kind or similar either.

So what´s the deal? I really don´t do any magic there. If an object of mine is not allocated, I allocate it. That´s all. It´s all only allocation and initialising of the data. No other processes, no running of any other code to make it initialise. Just usual allocation using C4Ds memory allocators (gNew/bNew).

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 15/10/2008 at 10:09, xxxxxxxx wrote:

Any information what the problem may be now?
I double checked my code and I don´t have any clue what may cause this. No double allocations, no missing memory freeing.

I also wonder why it works with certain flags and with other flags it shall not work. Doesn´t make much sense to me (especially when you say it´s not up to the flags. Then it should work identical for all flags).
Either there is a code problem, then it would show up for every flag not only for these two I mentioned, or there isn´t, and it wouldn´t show up.