PDA

View Full Version : memory leakage problem



marco.stanzani
9th March 2012, 15:32
hello
i am running into trouble with an application which work perfectly for some time, and the it locks as long as a number of iteration has been executed: i am suspecting memory leakage since this number is depending on the memory available on my (windows XP) PC: on machine A (2G RAM) it takes 12 to 18 iterations on average, on machine B (4 G RAM) it takes approx 50 iterations. When looking a t the Windows task manager I can also observe that memory is slowly growing as long as the number of iterations
'Lock' happens as soon as the program 'start' a certain thread: 'lock' happens since thread never start (supposedly because the thead cannot get free memory to operate)

I checked my code and
- storage is either static or 'automatic' (variable decalred inside the functions)
- 'new' objects are seldomly declared and promptly 'deleted' when non necessary
- *alloc functions are never used during the run time, but only during the initialization of the program (only one time!!)

I suspect that the issue may be due to the fact that I have a thread which makes the UART communicating with the main application and using many 'emit': is this an issue? should i take any countermeasure for this?

i am also looking for a way to 'profile' the application memory usage, please advice: Is there under visual studio a way to check / monitoring the memory and class allocation used by the program or thread?

sorry for not posting any code example: the program is quite complex and probably will not help

thanks in advance for your help

high_flyer
9th March 2012, 16:59
You can try this if you are using visual studio:
http://vld.codeplex.com/

Under linux you can use valgrind.

marco.stanzani
14th March 2012, 09:23
ok, think i have isolate the issue, which is not related to memory leakage (BTW, thanks for the advice, the suggested tool helped to tune the program)
it looks like that every time i perform a 'connectToHost' the allocated memory (i am loking at the windows task manager) increase a bit (the program does this many times)
I'll try to post some simple code example
thanks in advance to who'll look into this

marco.stanzani
4th April 2012, 18:17
another chapter to this story
The memory leakage is due a combination threads and timers (can I use a Qtimer outside a Qthread?? this is the point: it seems a huge limitation of Qtimer indeed ...)

Below the example code: the memory in growing everytime m_progSupply->start() is executing by the main (i can see this using the debugger but i cannot get into the code since this is a thread).
I cannot see any reason for this: timer instance is correctly deleted as far as i can see



main()
{
....
m_progSupply->start(); // progSupply is a parent class of Qthread
.....

}

---------------------------------------------------------------------------
progSupply::progSupply(QWidget *parent, Qt::WFlags flags)
: QThread(parent)
{
....
}

void progSupply::run()
{
m_UartTimer = new QTimer(this);
connect(m_UartTimer, SIGNAL(timeout()), this, SLOT(TimeOutUart()), Qt::DirectConnection);
m_UartTimer->setSingleShot(false);
StartTimeUart();

exec();
}


void progSupply::StartTimeUart()
{
m_UartTimer->start(UART_TIMEOUT);
}

void progSupply::TimeOutUart()
{
m_UartTimer->stop();

checksUart();

}

void progSupply::checksUart()
{
m_UartTimer->stop();

if (data == false) && (m_repeat == true)
{
StartTimeUart(); // re-arm timer
return;
}
else
{
emit endProgrammerSignal("OK");

if (m_UartTimer)
delete(m_UartTimer);

}

}

high_flyer
16th April 2012, 17:00
timer instance is correctly deleted as far as i can see
Its a very bad idea to delete an object in a slot which it self invoked.
Why are you dynamically allocating your timer?
You stay in run() all the time because of exec() - so you can just use a local variable.
You should also have a look at QMutex.
And finally, what you see in the process manager regarding the memory allocation doesn't have to mean its a memory leak.
The OS manages the memory for the processes, and doesn't allocate or free the memory 1:1 as you do it internally in your application - to save on cleaning/allocating operations.