Qt Application launching but not responding - c++

I finished migrating an application from Qt4 to Qt5, it compiles and runs but as soon as the main window is opened I cant do anything (interact with items, or click or anything). its just not responding. I tried debugging it but in the main.cpp reaches the return a.exec(); statement and trying to debug further than that is not posible, the yellow arrow wont go anywhere past that, and if I insist too much it eventually disappears. The functionality of the program is supposed to be alright, I only migrated it.
What can be causing of this problem? I would post some code but there are so many .cpps and I have so little clue about the issue that I dont know what to post.
I know its not much information, but if anyone has had this problem or knows something related to these symptoms please just say it, it will be better than nothing.
If I missed anything please tell me
Thankyou.
Some more info
Platform: Windows 7 x64
Compiler: MinGW 4.8 32bits
Application: 32bits
I did compile all the libraries and the app in debug mode (except some such as Qxt, which is compiled with the command line and zlib and Qt5SerialPort which includes the debug version itself)

Try disabling all child widgets in your main window and then turn them on one at a time till you find which one is causing the blocking.

Related

CodeLite closes terminal instantly

I'm a beginner in C++ and I started an Udemy course. In that course they recommend using CodeLite as IDE, so I decided to give it a try. In the course, they write a basic program that displays "Hello world!" to show how the IDE works. They compile then execute it, and a terminal window opens with the "Hello world!" message like normal.
In my case, after following the setup process step by step and using the exact same code as them, when I compile and execute the code, my terminal flashes for a split second and then disappears. In their video the terminal remains open but I thought that since they have an older version of CodeLite maybe in the newer one that I have, the terminal is supposed to close by default.
I went online and found people saying that a way of keeping the terminal open is by adding #include and system("pause"); on Windows, but in my case the terminal keeps behaving the same, and CodeLite doesn't report any problems. I've also tried cin.get(); with no success.
Any idea what could be causing this problem?
I had the same problem and I did these steps to solve the problem:
Uninstalled CodeLite.
Installed MinGW correctly.
Then reinstalled CodeLite.
Then did tutorial steps: Click Scan then select MinGW.
After I did these steps, it worked normally.
I had the same problem running Codelite on OpenSuse Leap 15.1. I eventually found a very simple answer. Go to the Settings menu, select Preferences and then Terminal, on the left towards the bottom. Change it to konsole to use the standard terminal, rather than the codelite-terminal.
I know this is an old question, but did not see the answer that worked for me. Debugging (F5) will close the terminal after completion.
However, running/executing (CTRL+F5) will not. Leaves terminal open. At least this is the case for me, and hopefully this helps someone out.
I know this is an old question, but CodeLite has a Project-level setting for "pause when execution ends" which will pause the program before the terminal closes so that you can see outputs and the like.
To turn on just right click on your project, go to settings, and it should be in the center of the general tab.
I went online and found people saying that a way of keeping the terminal open is by adding #include and system("pause");
And this is the wrong way to do it - the desire to leave the window open/closed is not meant to be controlled by your program; but the thing calling it. For example, you break the ability to run it as part of a headless script.
Much better would be to run it in debug and put a break point at the return of main, or to find the configuration option in your IDE that stops it closing the window.
I am not aware why CodeLite would behave like that. If you really added some pause or blocking call and it still closes, it looks like it is not really running the program (e.g. something breaks before that or something is misconfigured).
First, try to open a terminal yourself (e.g. cmd or PowerShell on Windows), and execute your compiled program there -- that way, the terminal will remain open. If that works, then compilation went fine, but something is wrong with CodeLite's configuration, most likely.
Otherwise, as a last resort, since using CodeLite is not strictly required, simply switch to another IDE/toolchain, e.g. Visual Studio (on Windows).
For some reason, after closing and reopening CodeLite, it now works, the terminal remains open when I run it from the IDE. I don't know what solved the problem since I've closed and reopened CodeLite at least 5 times before this without anything happening. Thanks for the help though.
I had the same issue. What I found wrong was that the compiler that I installed was 32bit and I was using the 64bit CodeLite version . Try Installing the 32bit CodeLite version and it should work fine.
It worked for me.
I had this problem also, I tried uninstalling and reinstalling code lite but the problem still occurred.
I went back and checked the Environment Variables in control panel and I had placed the systems variables in "Path" to the incorrect Bin directory.
I corrected the entry, uninstalled and reinstalled code lite again and the problem was resolved.
Hey I also had the same problem, doing the same course! What I did was to relocate my mingw-w64 folder, deleted the earlier path from environment variables and added the new path. I uninstalled CodeLite; not saving the user information. I actually downloaded the 14.0.0(64-bit) instead of the newer version 14.0.1(64 bit) . Then I did the steps that Frank tells you and it worked out for me.
I am completing the same Udemy course and encountered a similar problem of the console closing immediately. I encountered the problem for a workspace with 1.) a long name and 2.) ending with an underscore "_". I reduced the size of the folder name which also involved deleting the trailing underscore. This appears to have solved the problem. I encountered this problem with one of Frank's provided workspaces so I knew it was not a compiler issue.
I had an issue with section 20 of my Udemy course because it had parenthesis in the workspace folder name. "(STL)" at the end. Once I got rid of the special characters, it worked fine.
If pause("system"); or cin or restarting Program and whole PC solutions are not working, then make sure to:
Copy your code.
Create new Project and past your code there.
Make sure the new project is selected before trying to double-click it.
Notes:
You can now delete the old not working project and rename your new project.
I don't know what's the reason of the problem, but I did that and it worked for me.
You need to make sure if it is 64bits CodeLite then you have installed 64bits MinGW. Through the IDE itself, you can re-run the setup wizard
Restarting Codelite worked for me ...

Debugging a Qt application on Windows

my Qt (QML/C++) application crashes and I can not find the reason why. I tried to output a lot of information but some signal/slot connection probably causes a crash. I spent many hours trying to find the reason but I failed.
The only good point is that I can reproduce the crash whenever I want.
Unfortunately I don't know hot to use the included GDB debugger. This is the output I got:
How do I find from this what happened and where? I need to find at least the function, in which my application crashed.
Or what else could I try? Unfortunately I can not disable the signal/slot connections or the associated functions, because then I can not get to the point, where it crashes.
Qt has detailed documentation on how to install a debugger found here: QtCreator Debugger
MingW does have a GDB that can be used to debug the application better. You can also use CDB to debug, just depends on your preference.
Once that is installed, you'll be able to set breakpoints and check variable information to see where your program is crashing using the Debugger view in QtCreator.
Tools->Options->Build & Run
If you have Qt version kit like this you need to check debuggers.
https://i.stack.imgur.com/LaY1p.png
https://i.stack.imgur.com/8kTG6.png
You need to install MinGW and after install you will be have debugger. After install press F5 to start debuging.

OpenGL code runs perfectly from IDE, CodeXL and GPU PerfStudio, but gives blank screen if started from Windows

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.

Making C/C++ eclipse working

I do use to work in Eclipse cause i find it pretty good, but every day i am encountering this problem..."'Cleaning all projects has encountered a problem'. Errors occured during the build." when I hit the "clean projects" button. I have win 7 64 bit.
The only solution for this issue to work is to restart my computer. But I don't find it that good, because even if I restart my computer in the next 5 minutes when I compile a certain program it gets stuck again, it shows the same annoying message.
Please give me a solution to make this work. I wouldn't like to switch to visual studio...
It's hard to tell for sure, but your application might have some unreleased resources which 'clean' command can't remove. Did executable process terminate? If not, you whould have this error. You could try to remove binaries from build folder manually and see what file causes and error.

Application does not start in debugger

The application I'm working does not start in the debugger of Visual Studio 2005.
Here's what I do:
I rebuild the application and hit F5 to start it
The title of the VS2005-window says "projectname (Running) ..."
The debugger buttons appear but are greyed out
The application appears in the Windows task manager, but it has only 80k in memory usage
Nothing happens for a long while, and finally I get a windows with the following error message: "Debugging is being stopped but is not yet complete. You can force debugging to stop immediately, but any process being detached may be terminated instead. This window will automatically close when the debugging has completely stopped". The window does not disappear, so after a while I press the "Stop now" button.
Nothing happens for a while (the debugger buttons still visible, but greyed)
Some time later a new window appears: "Unable to start program '(path to exe)'. OLE har skickat en begäran och väntar på svar". The last sentence is swedish for "OLE has sent a request and is waiting for response". I press OK and the debugger buttons are gone.
The application is still running, and still has only 80k in memory usage.
I try to end the process with the task manager, but it is not killed.
I quit Visual Studio and finally the process is gone.
The application is an unmanaged C++ project, that use a lot of DLL-files as plugins. I'm using the "multi-threaded debug" runtime, and I've made sure all dependencies are compiled against the same runtime.
It was while doing that this problem appeared all of a sudden. I've tried to reverse my changes, but it doesn't help. Restarting the computer doesn't help either.
I've got the application running once or twice at random. If I then ended the application and started it again it wasn't started. So I don't think this is because of my configuration.
Any ideas?
One more note: the application starts and runs as it should if I start it from outside Visual Studio.
Sounds like a misbehaving DllMain() in one of the implicitly linked DLLs used by your program. You might get a hint from the Output window, it lists the names of the DLLs as they get loaded. If it is wininet.dll then you've fallen into a deadlock trap with the symbol server.
Ok, I've solved my problem, but I have no idea how.
One thing i tried was deleting all build files and exe and dll files, and then recompile everything. But that didn't help.
I then tried one thing at random: the plugins were in the same solution. So I removed them and tried to run again. And this time it worked! So I added all the plugin-projects back, and it still works!
So, I guess I will never know what happened. But removing and adding a project to a solution might solve someone elses problem too ... :)