Reputation: 777
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:
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;
}
}
Upvotes: 1
Views: 211
Reputation: 15579
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.
Upvotes: 0
Reputation: 93890
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.
Upvotes: 0
Reputation: 137930
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 by DSP
.
Other than that, there's not much we can do to intuit what's happening in your program.
Upvotes: 2