I'm working on my digital signal processing framework. To provide a data exchange interface, I wrap all buffers in a Data class, which has a reference count based GC mechanism(the system is simple enough so I believe ref count can handle this).
It works like this:
- When a Data instance is constructed, it sets its ref count to zero.
- When the instance is dispatched to N DSP modules, add N to its ref count.
- When a DSP module finishes with the instance, it reduces the ref count.
- When the ref count decreases to zero, it delete this;
However I found out that there is memory leak in my program.
To debug, I added static variables m_alloccount and m_freecount to the Data class to record the time of allocation and freeing. Then I pause the execution at random times, only finding out there is just slight difference between the two numbers.
E.g. in different trials:
Trial 1 2 3 4
m_alloccount 12 924 34413 364427
m_freecount 11 923 34412 364425
But the fact is that the memory usage is still growing. I believe all memory allocation is bound to the Data class. Really can't figure out the reason now.
int Data::m_alloctime=0;
int Data::m_freetime=0;
Data::Data(DataPinOut*parent, int type, int size)
:m_ptr(NULL)
,m_parent(parent)
,m_refcnt(0)
,m_type(type)
,m_size(size)
{
if(size>0)
m_ptr=new char[TypeSizeLookup()*size];
m_alloctime++;
}
Data::~Data()
{
delete [] (char*)m_ptr;
m_freetime++;
}
void Data::Delete()
{
std::lock_guard<std::mutex>*lock=new std::lock_guard<std::mutex>(m_mutex);
if(m_refcnt>1)
{
m_refcnt--;
delete lock;
}
else
{
delete lock;
delete this;
}
}
In my experience, a memory leak of just one or two regardless of the amount of internal operations indicates a leak of an input or output variable. Check the accounting consistency of the external interface of your system.
std::shared_ptr
is nice because being standard, it is automatically suitable as an external interface. The user can interact with ref-counted objects without knowing the management details defined byDSP
.Other than that, there's not much we can do to intuit what's happening in your program.
Step 2. Add n refs when dispatched.
Are modules guaranteed to be dispatched? Based on your simple algorithm statement a created module that is not dispatched has no mechanism by which its ref count would decrement and be deleted.
How are you maintaining your counters? If your counter decrement/test is not atomic you might be leaking decrements which would prevent the object from ever reaching a refcount of 0.