I'm using Qt 5.2.1 MinGW 32bit on a Windows 7 machine with gdb from the MinGW 4.8.
There is a strange behaviour when i try to singlestep through the code.
QFileDialog open;
open.setDefaultSuffix("tst");
QString fileName=open.getSaveFileName(this,tr("New File"),"",tr("Test File (*.tst)"));
if(fileName!="")
{
...
Im setting a breakpoint at the 1st Line.
Singlestepping works until the 3rd Line, than, after choosing a file, gdb says:
Cannot insert breakpoint -1217.
Error accessing memory address 0x7219cd30: Input/output error.
When i set a Breakpoint insede the if or after, the Debugger stops at the Breakpoint, but when i try to singlestep after the stop, the same error occurs.
When i set the FileName directly like:
QFileDialog open;
open.setDefaultSuffix("tst");
QString fileName="D:\path\to\File.tst";
if(fileName!="")
{
...
Singlestepping works without any problems.
The Code above runs without any problem, the problem only occurs when i try to singlestep.
Does anyone knows the problem, or a suitable workaround?
QFileDialog::getSaveFileName() is a static function, but you call it like a member method.
I'm only guessing, but probably the way you are calling a static member via an object confuses your debugging environment - the compiler should generate valid code though, so running over your code will work.
BTW, setDefaultSuffix will not work as expected, as getSaveFileName is a static member and will not look at your QFileDialog object.
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.
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
I've started using Compass, and it behaves really strange. When I use the watch command, it detects changes and rewriting the main CSS file as expected, but it randomly returns an error on some partial files and won't compile them into the main CSS file.
For example: When I change _fonts.scss, it works great. when I change _intro.scss the terminal gives me the following error:
modified sass/pages/_intro.scss
[Listen warning]: Change block raise an exception: undefined method `to_tree' for nil:NilClass
It is just a random error, it can happen with any file, and the only thing that solved it was pressing Cmd+C and using the watch again.
Files that were once compiled can now return this listener error, and vice versa.
Why is that? and how do I fix it? It's really slowing down the development to press Cmd+C and start the watch command every 10 minutes or so.
It might be a bug in Compass - see https://github.com/Compass/compass/issues/1851
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.
Firstly, I am not using visual studio, I am using notepad and csc. What I am trying to do is create exe's like visual studio's Windows Applications, that is, that do not open any console window at all when you double click the exe. I have found this:
[DllImport("kernel32"]
public static extern IntPtr GetConsoleWindow();
IntPtr window = GetConsoleWindow();
if(window != IntPtr.Zero) ShowWindow(window, 0);
and similar snippets, which work but the console still shows up for a split-second. I want it to not show up at all.
Also, using the Process class does not help because the exe is standalone and is to be double-clicked by hand, it is not launched from an already-running program.
I am also aware of using a vbs script to launch a bat that opens the exe, and other workarounds, but they do not suit my needs.
How can I compile the exe to merely open without any console window at all? It must be possible because visual studio's Windows Applications do it. To clarify I don't even want a form, I just want the program to run in the background, I only am referring to Windows Applications for the sake of comparison since they show no console.
Please don't give me any stupid answers like "use visual studio" or respond with a question instead of an answer. Thank you for your help!
you may want to use the unmanaged library kernel32.dll and the FreeConsole function. Here is an example:
[DllImport("kernel32.dll")]
static extern bool FreeConsole();
static void Main(string[] args)
{
FreeConsole();
// Do other stuff
}
Let me know if this is what you're looking for!
You can go only one way.
Create your (own) application as GUI subsystem, rather CONSOLE subsystem.
When you run compilers - use CreateProcess or ShellExecute (C++) with SW_HIDE (CmdShow). Can't remember, is there corresponding argument in C# function, thought - must be. If not - use WinAPI to start compiler.
This method will completely obscure console window.