QWidget: Must construct a QApplication before a QPaintDevice crash error

[eric_vi]

i am having 2 different plug-ins that work inside a non QT application... as long as i stay in debug mode all fine... when i go to release and deploy them... as long as i use the same plug in all fine...
when i start switching from one of the plug-in to the other i start to get this QWidget: Must construct a QApplication before QPaintDevice ... i am sure my QApplication has been created before i checked it out

it sounds more like the frameworks which are exactly the same (but dynamic, deployed and independent for each plug-in) are not unloaded and create a conflict

I taht possible? how can you make sure when you quit one plug-in that use QT frameworks without quitting the application that has launched the plug-in that there cannot be conflict of frameworks with a subsequent plug-in that is launched in the same session

[ChrisW67]

I have no idea what, "I taht possible?" is referring to or, indeed, much of what your post is trying to say.

What do you mean by "plug-ins that work inside a non QT application"? Are you talking about ActiveX controls on Windows or something else?
What do you mean by , "switching from one of the plug-in to the other"? Do you mean moving focus between widgets presented by the "plug-ins", loading and unloading the "plug-ins", or something else?

Where and how is the (singular) QApplication instance created? Where and how is that QApplication instance destroyed?

[high_flyer]

I think what he is trying to say is, that he has a non Qt application, which uses plugins which link to Qt.
This will also account to the sort of the problem he (probably) refers to regarding the construction of a QApplication.

@OP
Do you need to use Qt GUI facilities or services that need an event loop?
Consider very good what you relay need in your Qt plugins, it might be that you can get rid of all the event loop dependent code, which will free you from the need to have an instantiated QApplication/QCoreApplication in your plugins.

[eric_vi]

Hello again, thank you,

yes i have non Qt application (not made by me so i have no control over it. This application can call plugins following a user interaction. So a user can decide to launch a plug-in... Those plug-in use QT and do have a user interface and multiple QT frameworks are needed ( i do not use static QT frameworks)

i have sub classed QApplication

class myQApplication : public QApplication
{
public:
    myQApplication(int &argc, char **argv);
 
protected:
        bool    event(QEvent *);
 
};

class myQApplication : public QApplication
{
public:
    myQApplication(int &argc, char **argv);

protected:
        bool    event(QEvent *);

};

To copy to clipboard, switch view to plain text mode 

and as soon as the plug-in starts before any event loop i call
my_qapp = new myQApplication(argc, argv);


then my event loop

when i quit the plug-in i do
delete my_qapp;


All this works perfectly well in debug mode..

when i go to release i need to deploy it so each plug-in has its own copy of the frameworks.

In release mode, as long as i use one plug-in, ii can do multiple launch and quit, all works fine. The problem occurs when i quit one of the plug-in and launch the second one... i got this error message
and in console i can see some message that says that the framework of plug-in number 1 or the framework or plug-in number 2 might be used and that is where i am getting really confused.

[high_flyer]

There are some things you are not saying - for example, where/when (if at all?) you start the the QApplication event loop? (exec())


Try calling quit() on your QApplication before you delete it in your DLL, see if this helps.

[eric_vi]

the application uses only one plug-in at a time..


there are not many steps.. the crash occurs during the initialisation of my QMainWindow
as i am giving a minimum and a maximum size (setMinimumSize...)

so i have not reached the even loop yet

{
    MainWindow *w;
 
    my_qapp = new myQApplication(argc, argv);
 
    // MainWindow is a sub class of QMainWindow
    w = new MainWindow();
 
    my_qapp->exec();
 
 
}

{
    MainWindow *w;

    my_qapp = new myQApplication(argc, argv);
	
    // MainWindow is a sub class of QMainWindow
    w = new MainWindow();
	
    my_qapp->exec();


}

To copy to clipboard, switch view to plain text mode 

i do have any quit() when i delete my QApplication at exit time i will try that

[amleto]

{
    MainWindow *w;
 
    my_qapp = new myQApplication(argc, argv);
 
    // MainWindow is a sub class of QMainWindow
    w = new MainWindow();
 
    my_qapp->exec();
}

{
    MainWindow *w;

    my_qapp = new myQApplication(argc, argv);
	
    // MainWindow is a sub class of QMainWindow
    w = new MainWindow();
	
    my_qapp->exec();
}

To copy to clipboard, switch view to plain text mode 

what is this I dont even...

correct:

int main(int argc, char** argv) // please include method name etc so we have some context!!
{ 
    myQApplication my_qapp(argc, argv);
 
    // MainWindow is a sub class of QMainWindow
    MainWindow w;
    w.show()
 
    my_qapp.exec();
}

int main(int argc, char** argv) // please include method name etc so we have some context!!
{ 
    myQApplication my_qapp(argc, argv);
 
    // MainWindow is a sub class of QMainWindow
    MainWindow w;
    w.show()
 
    my_qapp.exec();
}

To copy to clipboard, switch view to plain text mode 

This is not java, dear.

[eric_vi]

i don't know about java... i had it this way before but because of this bug i was not exactly sure where the objects would be created so i tried with a 'new' allocator to see if it was making any difference

[eric_vi]

i tried to put a quit() when deleting the QApplication... this does not make any change...

when within the same session i quit one plug-in to launch another (each of those plug-in are deployed and have their own set of frameworks) I get this QWidget: Must construct a QApplication before a QPaintDevice crash error... i am running on Mac OS and if i examine the console log i can see that during the launch of plugin 2 i get multiple warnings such as

objc[722]: Class QNSStatusItem is implemented in both /Library/Application Support/plugin1/Frameworks/QtGui.framework/Versions/4/QtGui and /Library/Application Support/plugin2/Frameworks/QtGui.framework/Versions/4/QtGui. One of the two will be used. Which one is undefined.


i really have no clue why the frameworks from the previous plug-in launch can still be used!

[high_flyer]

Without seeing the real code its hard to tell.

[eric_vi]

i have described what the code is doing there is not much more to it

but let me describe again my issue, hopefully someone can give me some hints, because i am totally stuck...


i am in a deployed configuration (in debug mode i have no problem at all, since i am always using a unique framework).

i have an application (non QT), that launch thru user interaction PlugIn1 (QTmade that has been deployed and point to his own set of QT frameworks), all is fine so far...
the user quits PlugIn1 ( doing so the QApplication from PlugIn1 is deleted and i added a quit()), the Plugin1 process is gone and the user returns to the main application then launch plugIn2 (which is similar to PlugIn 1, deployed with its own set of QT frameworks)...
When launching PlugIn2... i can see in console mode a warning that QT might still use the frameworks of PlugIn1 (!!!!), and of course if it does so i got the QApplication before a QPaintDevice error, since PlugIn1 is no longer there and has been quitted before.

so my question... how can i make sure the qt framework binaries are not going to be used anymore when i quit a plug-in working on QT frameworks that is used within an application, because so far it does not seem to happen for me.

[wysota]

how can i make sure the qt framework binaries are not going to be used anymore when i quit a plug-in working on QT frameworks that is used within an application

The only way I know is to statically link Qt to your plugin. Otherwise always the first loaded instance of the framework will be used because libraries (as far as I know) once loaded into the process, stay there until the process quits. Therefore when plugin2 needs to resolve its Qt symbols, it does so against the set of libraries loaded for plugin1.

However I doubt this would give you the warning you receive. I'd say you were not freeing all the resources from plugin1 properly. I would also not delete the application object instance, I don't see the point of doing so -- you can reuse the same instance that the previous plugin used.

[eric_vi]

i might not been freeing them correctly i agree that is highly possible...

how can i for example free the whole QTCore, QTGui etc..

[wysota]

how can i for example free the whole QTCore, QTGui etc..

I'm not talking about libraries but rather objects. Without seeing what you really do it is hard to suggest anything. For instance you need to make sure you delete all the widgets you use. This is bookkeeping that you have to do on your own. Other than that I think the whole "plugin" concept you have is incorrect but again without knowing the big picture, I'm not able to say more.

[high_flyer]

Otherwise always the first loaded instance of the framework will be used because libraries (as far as I know) once loaded into the process, stay there until the process quits.

Unless you unload them.

Therefore when plugin2 needs to resolve its Qt symbols, it does so against the set of libraries loaded for plugin1.

Are you sure about that witek?
To my knowledge, each DLL is a process of its own - as I wrote in my previous post - each DLL is equivalent to an exe, AFAIK.

[wysota]

Unless you unload them.

I don't know any way of unloading a library that was loaded by the linker. You don't even have any "handle" to the library so I don't know how you'd like to unload "library X".

Are you sure about that witek?
To my knowledge, each DLL is a process of its own - as I wrote in my previous post - each DLL is equivalent to an exe, AFAIK.

When a DLL is loaded, it occupies some memory. Then this memory is being attached to every process that requests this library to be present. Therefore each DLL is loaded into memory only once and can be attached to multiple processes. There is no flow in the DLL itself, it is just a blob of code so it is not like a process -- it doesn't have its own stack, nor heap nor set of registers (and thus no instruction pointer). If you try to load the same library again, it is not loaded because it is already there. If one loads a library called "QtCore" then if someone (e.g. another library) requests a library called "QtCore" to be loaded again, the one that's already there will be used.

Now another thing is whether requesting library X loads it into memory or uses one that looks like X that is already present in the memory. This decision has to be made when the required symbol is not already loaded into the process. If we assume that libraries are not automatically unloaded when nobody wants to use it anymore (and I think that's the case) then if you request a symbol that is in the library (like "QApplication") then it is being resolved from the library that is already loaded.

So the bottom line is that unless MacOSX does something really weird with regard to frameworks then symbols from plugin2 are being resolved against Qt libs loaded by plugin1. I don't know what happens when the application explicitly unloads plugin1 (we don't know if that happens in this particular case), maybe it would unload Qt libs as well as I'd expect that the system holds a reference counter for each attached library on behalf of each process which at least seems to be happening on Linux -- as far as dlopen() manual is concerned. But I'm assuming plugin1 is simply not unloaded at all. In other words we don't know if an equivalent of dlclose() is called on the handle of the plugin1 library and whether it works.

[high_flyer]

I don't know any way of unloading a library that was loaded by the linker. You don't even have any "handle" to the library so I don't know how you'd like to unload "library X".

Under windows at least you do get a handle to your DLL.
A reference count is done for the used instances, and when you call FreeLibrary() if the reference is 0, the DLL is removed from your apps memory.
In such a scenario, a reference to a QApplication object would be lost in the calling application as well. (I'd expect).

[wysota]

Under windows at least you do get a handle to your DLL.

Only if you load it explicitly. Not if it's loaded implicitly by the linker. Try writing a simple application that links with QtCore and unload that library while running the program. In other words, modify this code:

#include <stdio.h>
 
int main(int argc, char **argv) {
  getchar();
  return 0;
}

#include <stdio.h>

int main(int argc, char **argv) {
  getchar();
  return 0;
}

To copy to clipboard, switch view to plain text mode 

SOURCES += main.cpp
QT = core

SOURCES += main.cpp
QT = core

To copy to clipboard, switch view to plain text mode 

... and make it unload QtCore before the call to getchar().

[high_flyer]

That is correct - but plugins are explicitly loaded, at least when I implement them, that is the whole point with plugins.

[wysota]

That's why I said that all depends on whether the plugin is explicitly unloaded or not. If not then you can't unload Qt that is implicitly loaded by the plugin.