Issue
I am having difficulty debugging inside of my application's timerEvent functions. While the application is able to run, if I set a breakpoint inside of even something as simple as the following, I receive an error message stating: "The gdb process crashed."
void MyClass::timerEvent (QTimerEvent *e) {
std::cout << "TIMER!";
}
I have included a debugger log here via pastebin.
Attempts
To try and fix this, I tried upgrading gdb iteratively with each version of QT-creator to no avail.
I am using:
Linux ubuntu-x86 2.6.32-42-generic #95-Ubuntu 10.04LTS SMP i686 GNU/Linux
QT creator (versions 2.4 through 2.5.2)
gdb (7.1 through 7.5) targeting "x86-linux-generic-elf-32bit"
pythongdb (7.2)
Questions
My questions are twofold, namely:
What is causing gdb to crash?
and
What can I do to make it work?
Failing that, I wonder: Where else should I look for more details of the crash?
Any and all help is greatly appreciated.
Make sure your QT libraries are up to date. Even though a new QT-creator will install via the handy-dandy .bin file they provide, it was built using the newer QT libraries, and expects them to be in place. If they are not, well...
Additionally, if you are not installing gdb into one of the standard directories where QT-creator can find it, make sure you add it manually to your toolchains via tools->options->build and run->toolchains.
Related
After the setup I've done in the properties of the project: at C++Compiler and Linker in both Release and Debug configurations I tried to build the project, which went successful.
Then I decided to run it and had some difficulties: using External Terminal, that did absolutely nothing, Standard output, that showed some text related to dll files I've clue about, Internal Terminal, that showed the very same text.
After that didn't work I went for cmd execution and what I saw was this.
Could you explain what that means and what I'm supposed to do. I'm new to all that kind of stuff, so I apologise if I did something stupid.
Cheers
EDIT: If not seen, I'm using Windows 10 and the version of SFML is GCC 7.3.0 MinGW (DW2) - 32-bit
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.
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 OSX Yosemite 10.10.5, QtCreator 4.1.0, Qt 5.7.0 and Xcode 7.2.1.
If I write any native C++ program in QtCreator (console, gui - anything) I am unable to debug that program from QtCreator. Breakpoints get ignored, the program executes without pause and runs to completion no matter what I try.
I have tried the Xcode's LLDb, system GDB and Homebrew GDB as debuggers. the versions of GDB fail to start. Homebrew GDB has been codesigned.
This all used to (a few year back) just work beautifully and I am at a loss as to what might have changed.
Curiously, if I generate an exception inside the program - like accessing through a null pointer, the debugger shows me where this happens in just the way I would expect so, presumably, the debugger is running but simply treating me with complete disdain.
I know there are many versions of this question but none seem to address the problem adequately or offer workable solutions, or they apply to much older versions of the products.
Any suggestions?
This version of qtCreator (4.1.0) saw the return of the warning about having the build directory at the same level as the project directory. In Windows, this is done automatically. My mac installation does not get it right. (I may have messed a while back - cannot remember).
So - if the build directory is inside the project directory, debugging fails. Move the build directory up to the same level as the project directory and everything seems to work fine.
You can set the default build directory in the preferences/Build & Run dialogue. The path should start with ../
You will need to think about the folder structure before setting up the project unless you want build folders appearing in awkward places. So, a project folder structure like this is OK:
But one like this is not:
If this was already obvious to you, great. I have been messing with this for ages.
Many thanks to those who replied and anyone else who took the time to read the question. What helped e find it was the suggestion by #AlexanderVX that his setup was the same as mine but his worked. The only bit of my setup he could not see in the screenshots was the start of the build path. So that was the clue.
I have successfully built OpenCV and I have come to the point where code::blocks recognizes the OpenCV syntax and successfully builds the program. However when I run I get this error
"The procedure entry point_gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll."
I am using Code::Blocks v 12.11 and minGW (the most recent, I can't remember the version number) along with OpenCV-2.4.8 Has anyone ever seen this problem? Help if you can, anything right now might work since I am so close.
https://stackoverflow.com/questions/3895879/installing-opencv-on-windowsw32-to-be-used-with-code-blocks?rq=1
Using this link to the other question I was able to locate a hint for my problem. I had everything correct and the hint to change the build to a GUI Application solved the issue. The programs build and then run as they should.