memory leak?

[verbatimline]

I have an input and output MArrayDataHandle.  The input size determines the number of elements in the output.  I do stuff with matrices and vectors and output vectors using an MArrayDataBuilder.  Everthing works fine up to 11 or 12 input elements.  Anything more than that and the output vectors seem to have their values shifted.  I know for a fact (because I fprint them) that the y value should be -.06 in all of them.  So my internal calculations are correct. But when I output them to the array, the -.06 value appears on the z or sometimes on the x element of the output attrs.  What can possibly be happening?  Is this some sort of memory problem?

Tim

[joojaa]

What can possibly be happening?

most likely you ahve a indexing issue in your code.

[verbatimline]

so I figured out that it is not the DataHandles.  They are outputing exactly what is given to them.

I checked. It is not an indexing thing.  I assign value in a straight loop from 0 to number of elements.  What is interesting is that more often than not, it happens at index 0 and at 8.  In the class I declare a private member of type MPointArray.  This MPointArray is then setLength(4) in the postConstructor.  I also setIncrementSize(4) in postConstructor.   This MPointArray (as well as many others of the same type) are accessed at the top of the compute function.  They print predictable values at the top.  Somewhere in the middle, the y value starts appearing in the x or z component.

BTW.  I'm using private members of type arrays because it is my way of retaining values from the previous frame.

It prints to something like this:

it should read:
INDEX: 0
pointWS: [3, -.06, 8]
INDEX: 1
pointWS: [3, -.06, 7]
INDEX: 2
pointWS: [3, -.06, 6]
INDEX: 3
pointWS: [3, -.06, 5]

what I get:
INDEX: 0
pointWS: [3, -.06, 8]
INDEX: 0
pointWS: [-.06, 8, 1]
INDEX: 0
pointWS: [3, -.06, 8]
INDEX: 0
pointWS: [3, -.06, 8]

again, this error begins to happen when I add more that 9 or 10 elements.  Any more than that I it goes crazy.

[verbatimline]

found the solution.  I check the difference between the size of input array and my member array which is initialized to 4 in the post constructor.  I then append the difference to the end of my member array.  I was under the impression that if I setIncrementSize to 4, anytime the array needed more indeces it would increase its size by 4.  It failed to do that and so I was referencing unknown areas in memory.  I think that is a bug, correct?  Anyways, it works now by explicitly increasing the size of array.  Must do for MDoubleArrays and MIntArrays.

[joojaa]

Or confusing documentation, result is same thing tough.

I personnally avoid the bug word, because the bug implies something unintentional and minor. Besides its usually unproductive to make this assertion, for most persons bug is a sort of a blame sink that allows them to shift the blame away from themselves. Even surprisingly the developers are allowed to do that. What i personally think they should be called is mistakes, flaws and inconsistencies. These are much more easier to agree on, first mistakes are unintentional, and generally we all seem helpfult about fixing mistakes, even OTHER peoples mistakes. Flaws are things that are broken is some significant way, usually you can not even begin to work around a flaw. Despite this flaws are often intentional side effects or rational choices as opposed to mistakes that were never intended. Flaws as a category need to be reflected on the whole picture. The most infuriating but common form of a problem in code is the inconsistency, it just sucks its sort fo a mistakes that is applied chaotically in the design, these are hard to track and even harder to eradicate, They make your dev times go to crawl and they NEVER ever get truly fixed.

Bug or not your users dont care one way or another. The big failure of any engineering is the failure to understand your audience.