I have a QT application that works well in the debug version but not in release. The release version runs with no crashes or anything, but none of the QImages I use display. I'm pretty unsure what could be causing it.
I've seen this post here and am currently checking for any values that aren't manually initialized.
However, in the mean time can anyone think of why QImages would display in a debug build but not a release build?
Note that I'm running both from QTCreator. I'm on Windows 7 using Creator 2.7.2 and QT 5.1.
I haven't supplied any code because I'm not sure what I would post given there are no issues in the debug build (but I can if it would make things clearer).
Indeed the issue was a variable that was automatically set in the debug build.
I needed to manually set it for the release version and now my QImages seem to be displaying just fine.
Related
I'm using Qt 5.8, with clion as IDE, made with bundled cmake 3.7.2. Using Mingw-w64, x86_64-6.3.0-posix-seh-rt_v5-rev0, which came bundled with GDB 7.11.1. Using Qt5.8 version from msys2 supposedly compiled with the same version of mingw-64 (couldn't get QT to compile on my system, so that was my only option). This problem seems agnostic to what I'm doing specifically, I'll often have code that works perfectly, no crashes, segfaults or whatever, and when i do the same things in the debugger it hangs for 30 seconds trying to open the QFileDialog, slowly loading the gui as if its going to work, before quickly crashing saying "Gdborig.exe has stopped working".
Not sure what other context I can provide, as again, only appears after doing the following calls:
QString fileName = QFileDialog::getSaveFileName(m_parent, QObject::tr("Save File"), QString(), QObject::tr("*");
but it doesn't matter what static method I use, same thing happens on getOpenFileName, and getOpenFileNames. There doesn't seem to be any pattern strictly speaking to the crashing, there are times I can get past it, and there are times I couldn't. I originally had a hypothesis that because I was using -pg -Og flags when the issue first appeared that these caused the issue, but I have since removed both of these flags and the issue persists.
I have seen similar behaviour in otherwise perfect applications and I was able to work around this by adding QFileDialog::DontUseNativeDialog as final parameter to the QFileDialog calls.
So I think, this is a COM-apartement issue of the native Windows libraries. But I have to admit, this is a very wild guess.
I have been improving an OpenGL code of my own since some days, and now I got a terrible surprise: My code works properly if run from inside CodeBlocks IDE (by Menu-> Build -> Run), but if I open it from the Windows Explorer, the program will still open and issue messages on the console as if it would be running properly, but I just get a blank screen.
I have trying re-building the code to see if the problem disappears from Windows, or to see if it also affects the run from inside CodeBlocks, but the outcome is still the same.
Some days ago (before much of the code change), I could start the program from both Windows and CodeBlocks and run perfectly in both cases, so this is totally surprising for me now.
I use GLFW3 and GLEW and I am linking to the following libraries:
C:\msys64\mingw64\lib\libglew32.dll.a
C:\msys64\mingw64\lib\libglfw3.a
opengl32
C:\msys64\mingw64\lib\libsfml-system.dll.a (I use the clock of this library)
gdi32
On the meantime I have deinstalled and installed msys64, but this didnt affect my other OpenGL projects linking the same libraries, so I suppose this is not the source of the problem
How would I proceed to debug such an issue? I have no clue about how to start troubleshooting this, so any comment on what extra info I should post is welcome.
Update: If I open the application from the GPU PerfStudio and CodeXL, everything works just fine, but not when I open via Windows Explorer.
How would I proceed to debug such an issue?
When I deal with bugs like this I use a tool called CodeXL. You can download the latest version here. It automatically breaks on any OpenGL error and shows you which of your OpenGL function calls caused it.
It is free and it works also with non-AMD GPUs.
It should not take you long time to learn how to use it: you just create a new project, give it path to your project folder and .exe and hit run. (make sure that Debug->Breakpoints->Break on OpenGL error is checked)
//Moreover, it visualizes your buffers, shows you your loaded textures, etc.. Definitely check it if you plan to program more Windows+OpenGL in the future.
I've noticed in Qt 5.5.0 and in Qt Creator 3.4.2 (built on Qt 5.5.0), that Actions attempting to use Ctrl++ are not working. Note that the shortcut works correctly in older versions (for example, Qt Creator 2.7.0 built on Qt 5.0.2).
For example, if I try to increase the font size in QtCreator using Ctrl++, nothing happens. The same is true for the ImageViewer example. (Ctrl++ in the ImageViewer increases the image size, but in 5.5.0, it does not work.)
If I bind increasing the font size to another shortcut in QtCreator (via Tools->Options->Environment->Keyboard), such as Ctrl+Z, it works fine.
I did a little debug by overriding keyPressEvent, and it appears that Ctrl++ is being sucked up earlier in the dispatch, but I am having trouble figuring out exactly where.
My questions are:
Is this a bug?
If not, does anyone have any advice on how to see how the key is being dispatched?
This is a confirmed bug in Qt 5.5.0 and appears to be fixed in the latest builds.
There is more information here:
https://bugreports.qt.io/browse/QTBUG-47701
I'm trying to use QT Creator for an open-source project I downloaded from github.
After some fuddling around I managed to get the project to compile in QT Creator and run in debug mode.
However, I have an issue : strangely the breakpoints that I set are only available for that instance for the debug run for QT Creator. When I stop the debugging, and relaunch the debugging, the previously stated breakpoints are still there, but they are no longer valid. (meaning Qt Creator skips over them). I've verified that new breakpoints are still valid - it's the old ones that become invalid even though they are still listed.
I did not even update any code, just added breakpoints, hit debug and the old breakpoints became invalid even though they are still showing.
No sacarsm intended, but is this a "feature"? If so, how do I turn it off?
If not a feature, what can I try?
It's very painful to re-add breakpoints every time I run a debug.
Using Mac OSX 10.9 here, Qt 5.2, with Qt Creator 3.0 for Mac.
Thanks.
EDIT : Some more info. I realised that whenever the breakpoint works, it has a tiny hour glass next to it, like in the picture. What does the hour glass mean? It could just be something dumb that I'm not doing....
in the end I filed a bug with Qt Creator. For those interested pls check here.
https://bugreports.qt-project.org/browse/QTCREATORBUG-11184
I had a working C++/Qt application. I updated MinGW, Qt and Qt Creator to the latest versions, and now I get an error at compile time. This error does not seem to be due to my code, but to the build system.
E.g.:
17:11:15: Running steps for project MyTest...
17:11:15: Starting: "C:\Qt\qtcreator-2.6.0\bin\jom.exe" clean
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
17:11:20: The process "C:\Qt\qtcreator-2.6.0\bin\jom.exe" exited with code 3.
In the project settings there is the message "qmake: No Qt version set. Cannot run qmake."
My source code is just what you get automatically when you create a new application.
I updated the system environment path with the new Qt and QtCreator directories.
I do not know what else to do...
Thank you!
---
Windows 7
MinGW
Qt 4.8.4
Qt Creator 2.6.0 (based on Qt 4.8.3 32 bit)
Please go to Tools->Options->Build & Run->Kits and check that there is a Qt version set up in the kit you are using.
If not, then check the Qt versions creator detected in Tools->Options->Build & Run->Qt versions. Is the version you want to use there? If not: Add it here.
Then return to the kits page and set one of the kits to use that version. Double check the other information while there.
Now you should be able to build your project. You might need to close/reopen it though.
Initial setup seems to be a bit bumpy... but it works really well once you get over that initial hurdle:-( There are quite some improvements in the next update for this. Check the Qt 5 RC2 packages, the creator included there already contain most of the fixes if you are curious).