AnsweredAssumed Answered

Memory leak when deleting arrays of objects.

Question asked by Peter847 on Sep 19, 2013
Latest reply on Sep 19, 2013 by Peter847



I am developing a VDK C++ application for the BF534 processor using VDSP++ 5.0, update 10.1. I find that when I dynamically allocate an array of class objects (using the 'new' operator) the system is allocating 16 bytes more than is needed and then failing to recover the extra bytes when I call delete. The code fragment below shows how I can allocate an array of 3 class PointF objects and then delete them. Using the space_unused function I can monitor how much heap has been used. The comments on the code fragment show the return values from space_unused on each call. I find that I always lose the 16 bytes regardless of the size of the class and regardless of the number of elements in the array. I have tried other class types and they behave similarly. If I allocate memory for a single element (PointF* pts1 = new PointF;) then there is no memory loss. I can allocate arrays of primitives (e.g char, int or double etc) with no trouble.


               int bytes = space_unused();               // 0xB88668

               PointF* pts1 = new PointF[3];      

               byte = space_unused();                    // 0xB88658

               delete pts1;

               byte = space_unused();                    // 0xB88658


There is one other anomaly. If I try to allocate an array of size 1 the compiler allocates 16 extra bytes and delete fails to recover any of it so the leak is larger when the array is only 1 object in size.


The definition for the PointF class is shown below.


class PointF




    PointF(double x, double y);


    // Should be able to rely on the default copy constructor for this simple object.


    friend bool operator == (const PointF& pt1, const PointF& pt2);

    friend bool operator != (const PointF& pt1, const PointF& pt2);


    double X;

    double Y;



I could use the sizeof operator to calculate the size of memory required and cast the resulting memory block to be a pointer to the class I am storing, but that is a bit long-winded. Is this a known bug or am I doing something wrong?



Can anyone shed any light on this?