My application has qml as frontend and c++ as backend.
To check some issues, I want to forcefully made qml to crash.
Mainly I am interested what error message comes up when qml crashes on client site so that we can handle those error better.
I have tried few things like assigning null values or null pointer on QML page but it doesnt make application crash.
From C++ side, I load application from QQmlApplicationEngine.
Any advice will be helpful.
You can use debug mode in Qt Creator.
And the application will stop when it crashes. Then, you can check your stack.
QML won't crash :)
You can't really make some pure QML/JavaScript code "crash", at least not the same way that you can shoot yourself in the foot in C++.
Remember than QML and JavaScript are interpreted, and any error will typically generate a QML warning. Something like:
qrc:/main.qml:33: ReferenceError: timer is not defined
This error will interrupt whatever operation you're performing in your local scope, maybe mess-up a few bindings or not do exactly what you expect, but it won't "crash" your QML application.
But you can always crash your app
If you expose some C++ component to your QML, you can technically crash your app from QML by triggering some buggy C++ code from your QML context. But this is the same thing as crashing your app from your C++ backend....
You can catch errors (locally)
When dealing with QML/JavaScript errors, you can catch these errors the same way you would in regular JavaScript code, using try { ... } catch(e) { ... } mechanism, as demonstrated in Catch QML error message
You can report errors (globally)
Even though not catastrophic, an error in your QML may impact the behaviour of your QML UI. One possible possible way to prevent this is to write tests for you UI where you exerce your QML components in various ways to ensure no errors ensue.
One trick we use in our test code (could work in production too), is to override the default log handler and watch out for QML errors and warnings. This allows us to test our QML components (do they behave as expected?) and also verify that no warnings were generated during these tests. The relevant documentation is available here: http://doc.qt.io/qt-5/qtglobal.html#qInstallMessageHandler
Related
I am using Qt5 for off-screen rendering and have a segmentation fault when running inside Docker.
I have the code inside a c++ and calling the function via python using pybind11
This is the code causing the segfault
QSurfaceFormat glFormat;
glFormat.setVersion(3, 3);
glFormat.setProfile(QSurfaceFormat::CoreProfile);
glFormat.setRenderableType(QSurfaceFormat::OpenGL);
surface = new QOffscreenSurface();
surface->setFormat(glFormat);
surface->create(); // <-- Here
The exact error is :
QObject::connect: Cannot connect (null)::destroyed(QObject*) to QOffscreenSurface::screenDestroyed(QObject*)
I tried to run it via xvfb-run -a python prg.py and got the same error
Any pointers to debug this?
A little more context to the issue , the above code works fine if I use it inside main thread wrapped in QApplication. This problem occurs only when I move it inside a function so I can call it inside python.
Your last clue about running outside of the main thread is probably the problem you are running into.
Looking at the docs https://doc.qt.io/qt-5/qoffscreensurface.html#details:
Note: Due to the fact that QOffscreenSurface is backed by a QWindow on
some platforms, cross-platform applications must ensure that create()
is only called on the main (GUI) thread. The QOffscreenSurface is then
safe to be used with makeCurrent() on other threads, but the
initialization and destruction must always happen on the main (GUI)
thread.
So the solution would probably be to create the surface in the main thread and then just use it like you need it via pybind11.
I got error when execute code. I think it's not related to code. something is missing.
java.lang.IllegalStateException: Problem in some module which uses Window System: Window System API is required to be called from AWT thread only, see http://core.netbeans.org/proposals/threading/
You have flagged your post with JavaFX, so I assume you are talking about a JavaFX application. Every GUI update in the JavaFX-world is done on the JavaFX application thread. Your exception however indicates that you are using some AWT code in your program which has a different requirement. It must be run on AWT thread. So, the first thing you have to do is find out what this code is and then you have to make sure to call it on the right thread. You can use Platform.runLater() to put something on the JavaFX thread and SwingUtilities.invokeLater() to put something on the AWT thread.
I have a Qt Application that works in Debug mode without any problems. Since two days I'm trying to make it work in Release mode. After some Project property modification I managed to compile without errors. But unfortunalty the application crashes before even reaching the main method.
That's my environment:
MS VS 2010
Qt 4.8.4
Qwt 6.0.0
I don't know if this is relevant, but I also installed the Qt plugin for VS and used Qt Designer to create my GUI.
As I said in Debug mode there is no problem. Starting the release version from the Visual Studio produces the following error:
Unhandled exception at 0x77c415de in Application.exe: 0xC0000005: Access violation reading location 0x0000000c.
The last function I can "debug" is the the "WinMain" method called inside the method "__declspec(noinline) int __tmainCRTStartup", which is located in crtexe.c (honestly I have no idea what this is). The call stack looks like this:
ntdll.dll!77c415de()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!77c415de()
ntdll.dll!77c3014e()
msvcr100.dll!718f0269()
msvcr100.dll!718f233b()
msvcr100.dll!718f233b()
msvcr100.dll!718f233b()
QtCore4.dll!5b2cfc49()
QtGui4.dll!57bf54ea()
Application.exe!__tmainCRTStartup() Line 547 + 0x1c bytes C
kernel32.dll!754633aa()
ntdll.dll!77c59ef2()
ntdll.dll!77c59ec5()
In the moment I'm totaly lost with this problem. No idea what to try further...
I've tried to reduce the program and commented out the complete main function. But the result was the same behaviour. As I said the error occurs even before the main function is called. I also turned off all optimization and recompiled... didn't changed anything.
What completly puzzles me, is the fact that it "works" when I call "Application.exe" from the command prompt (ok it also crashes but much later during execution). Weird, isn't it? What is the difference between starting from command prompt and starting from Visual Studio application?
AnatolyS and npiau thanks for you tips. Meanwhile I continued digging in my code. More or less I started from the very beginning and finally got the place the error occurs. I suppose npiau is right, it has nothing to do with Qt.
It's still (for me) a strange problem. I posted it in a new thread (because it has little to do with this thread): C++ Creation of a Singleton object in initializer list causes an Access Violation (only Release Mode)
The problem is not in QT but in your source code. "0xC0000005: Access violation reading location 0x0000000c" means that you try to access a wrong memory location.
Check out your arrays, ans pointers.
I am writing a Qt application that calls QProcess::startDetached("wscript.exe script.vbs") to show the delete confirmation dialog in Windows.
this is the script:
Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace("-")
Set objFolderItem = objFolder.ParseName("-")
objFolderItem.InvokeVerb("Delete")
the arguments for Namespace and ParseName are from the arguments passed to the script.
This may be inefficient because it opens an external application first before running the script. I was wondering if i can run VBScripts in a Qt application.
If not, what alternatives can i do?
My VBScript is very weak, so I'm not 100% sure I understand what you are trying to do. My assumption is that you are trying to delete a folder, but want to give the user the normal confirmation box and animation while the action is occurring. If that is not correct, please let me know and I will remove this answer.
A few ideas:
You could call the Windows API directory within your C++ code to do this. I believe the correct call would be to use IFileOperation (Vista and later) or SHFileOperation (pre-Vista)
Qt already has message box dialogs. Although you might not get the exact same functionality as the native shell, you could use this (QMessageBox::warning) and then delete the folder using QDir. This would also be cross-platform portable.
If you stick with the VBScript, I doubt you would see any performance issues unless this is being called many, many times in a loop or something. You know, the old "premature optimization is the root of all evil" thing.
You should read up on the IActiveScript COM interface. You can create an instance of an interpreter that implements IActiveScript to provide a runtime for evaluating scripts. VBScript and JScript can both be used for this and a number of other third-party scripting languages also provide IActiveScript support.
The overview for working with this is you create a language runtime (an instance of VBScript for instance) then add some custom objects to it. Typically if you are embedding an interpreter into your application then exposing an Application object is a good place to start. This can be just an IDispatch interface or something more concrete with an IDL generated typelibrary and all the trimmings. Once you have added the necessary named items into the runtime you load one or more scripts. Any public functions or subroutines declared in the scripts now get exposed via the IDispatch interface of the live runtime once you switch its state to active or running. To actually run the script program, I invoke the Main function for my stuff - you could choose some other scheme as applicable to your environment.
The nice thing about ActiveScripting, is to change language you just change the runtime CLSID. So if people prefer Perl they can use PerlScript or PythonScript etc. Your Application object remains the same hence you don't have to write additional code to support the new languages. The only requirement is that everything is COM.
I am writing a plugin for another application. I want to support the plugin on multiple platforms, so I am strongly considering using Qt.
The plugin needs to be able to show some basic GUI. The plugin interface does not in any way handle GUI - it is just a simple DLL/shared library specified with a C-header file.
Can I use Qt inside such a shared library? The calling application might or might not be using Qt itself. Any hints on what to do? Do I need to run a QApplication event-loop in a separate thread? Or can I just call the event-loop myself while waiting for input? (I only need modal dialogs).
I don't think it is possible because you need to create the QApplication eventloop in the main thread.
Note that QCoreApplication::exec()
must always be called from the main
thread (the thread that executes
main()), not from a QThread. In GUI
applications, the main thread is also
called the GUI thread because it's the
only thread that is allowed to perform
GUI-related operations.