QCoreApplication!!!!

[fellobo]

This is really ugly.... I am using Qt 4.0 and working in MVS 2005. I created a class that uses Qt items such as QSqlDatabase, and other QSql classes along with QString QStringList. Then I took my class and made a BOOST Test to test my class. I started getting some memory leaks. So, me and another Software Engineer looked deep into QT and found that these memory leaks came from not have a QCoreApplication. Easily fixed, or so we thought.... We included a QCoreApplication and now we don't get the old memory leaks but rather a new set of memory leaks all related in QCoreApplication. :confused:

I built a console app and used the same class and it didn't produce any memory leaks, this is without the using the QCoreApplicaiton and with using it.

I really don't think BOOST is causing the error because the errors changed when I included the QCoreApplication, but rather BOOST is just brining out an error in the QT code. Anyone have any ideas?

Thanks!

[jacek]

How do you define a memory leak? How many QCoreApplication objects do you create?

[fellobo]

Detected memory leaks!
Dumping objects ->
{287} normal block at 0x0103BE10, 56 bytes long.
Data: < . , ; % > 1F 00 00 00 E1 00 00 00 2E 00 2C 00 3B 00 25 00
{286} normal block at 0x0103BDE0, 4 bytes long.
Data: < , > D8 2C A7 00
{212} normal block at 0x01036BC8, 20 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 CD CD CD
{211} normal block at 0x01036B40, 92 bytes long.
Data: <P. k > 50 2E A7 00 08 6B 03 01 00 00 00 00 F4 D4 B3 00
{210} normal block at 0x01036B08, 8 bytes long.
Data: <X. @k > 58 2E A7 00 40 6B 03 01
{209} normal block at 0x01036AC8, 20 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 CD CD CD
{208} normal block at 0x01036A70, 40 bytes long.
Data: < k > 01 00 00 00 08 6B 03 01 00 CD CD CD 00 00 00 00
Object dump complete.


I placed one in each function. I have three functions.


void func_one()
{
QCoreApplication a;
....
}

void func_two()
{
QCoreApplication a;
....
}

void func_three()
{
QCoreApplication a;
....
}

void main(....)
{
func_one();
func_two();
func_three();
}

[wysota]

You can have ONE application object in your application. It's not called "QCoreApplication" by accident. Create it in main() instead. Anyway I doubt it will fix those memory leaks. Could you please explain the dump you posted?

[fellobo]

Okay, I am not entirely sure what is going on with my code. But, I removed all my functions but one, that included the QCoreApplication, and then ran it and got a new set of errors; the first error came in from BOOST and then all my QT errors. So, from this I came to the conclusion that the BOOST isn't cleaning up the memory like I think it was and will not bother the wonderful QT developers with this question.

Although, as to the multiple QCoreApplication I am still somewhat confused. :confused:

Why couldn't you have three different CoreApplication running? I am thinking, in theory, that you could have two threads that each thread would have a core application.

Don't get me wrong - I hear the words, duh you can only have 1 CORE application that is why they call it CORE..... and then in the back of my mind I think yea but why not have many core application? Maybe I am just frustrated by this bug.

Once again I thank you for your time!:D

[Brandybuck]

<rant>
There are many opinions as to what is a "memory leak". BOOST may be detecting memory leaks that are not leaks at all. Think about it: how do you know there is a memory leak? How do you know that the application is done using the memory? It is not an easy question to answer. Most leak detectors assume certain usage patterns. But what if these assumptions are wrong? If there is no reference counting, then the only way to know for sure is if there is still allocated memory when the process ends.
</rant>

QString and QStringList do not need QCoreApplication. But many of the QSql classes will, as they are meant to be used in a Qt application. The QCoreApplication is a singleton-like class. There should only be one per application (as it states in the documentation). This is because they contain the central event loop, among other things. The Qt architecture expects there to be only one QCoreApplication per application, and it expects it to be running in the main thread.

Qt is an application framework, not a collection of independent mix-and-match parts. Except for some obvious exceptions (QString, etc.), it is going to be difficult using Qt classes outside of Qt applications.

[wysota]

But many of the QSql classes will, as they are meant to be used in a Qt application.

In fact SQL support will not work in its most common configuration (using plugins) without QCoreApplication, as it is the application object that is responsible for loading and initialising plugins. If you don't have an application object and you try to add a database to your program, you'll end up with a "Driver not loaded" message.


Okay, I am not entirely sure what is going on with my code.
That's not a good thing :)


But, I removed all my functions but one, that included the QCoreApplication, and then ran it and got a new set of errors; the first error came in from BOOST and then all my QT errors. So, from this I came to the conclusion that the BOOST isn't cleaning up the memory like I think it was and will not bother the wonderful QT developers with this question.

Try investigating the below program for leaks:


int main(int argc, char **argv){
QApplication app(argc, argv);
QWidget wgt;
wgt.show();
return app.exec();
}



Why couldn't you have three different CoreApplication running? I am thinking, in theory, that you could have two threads that each thread would have a core application.
Why would it need a "core application"? Each thread can have its own event loop (using QThread::exec()), so I don't see a point in having more than one application object.


Don't get me wrong - I hear the words, duh you can only have 1 CORE application that is why they call it CORE..... and then in the back of my mind I think yea but why not have many core application? Maybe I am just frustrated by this bug.

My suggestion is to read the docs a little at what the application object does.