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 am trying to debug a library for a third party software. I have the source code of the library and I have compiled it using -g. I need to start the software to use the library and debug. AFAIK I have to start the program, then from gdb use attach and the id of the process. I am doing this, but gdb says "Can't attach to process".
Does anyone know why might this be happening?
Try to start it with gdb, just inside, having it attached in the gdb call.
gdb your_program_name
run your_parameter1 your_paremeter2...
I am trying to debug a problem with an application on Linux. It tends to crash with SIGSEGV in random places at libstdc++.so or libstdc.so.
There seem to be no obvious race conditions anywhere, as the job in the thread I added is very isolated. But it still crashes almost all the time.
The application is compiled with g++ -c ... -pthread -D_REENTRANT, and linked with g++ -pthread -o ...
But it's still crashing almost all the time in one of the libstdc*.so functions. I have wasted a few days on trying to figure out what's wrong, but no go...
Does anyone have any tips? Is there a way to make sure libstdc*.so is compiled as thread aware? Any gdb commands that could help me? Debug heaps?
I'm working with Linux for only a few years, so I'm lost...
There are few things you should do :
run your application using hellgrind
run your application using valgrind's memory check
run your application using DRD
Write unit tests. Although they do not help much in finding problems with threads, they can help you greatly with finding wrong memory access problems.
Try using -g when compiling if you're not already, to get symbolic debugger info.
Do you get a core dumped? If so you can use gdb to load the core against the executable as follows:
gdb <my-exe> <my-core-file>
Once loaded (presuming you compiled with -g) you can use info threads to get a list of all the threads stacks and take a look at the thread which caused the problem. If you follow the stack trace which caused the seg fault back up from the libstdc++.so or libstdc.so it should be reasonbaly obvious what's happening. At least it will get you to the right area.
If you don't get a core, can you run your app within the debugger itself?
This technique is also very useful fo getting to the bottom of thread deadlocking: Simply attach to the process using:
gdb <my-exe> <my-process-id>
and look for the two threads which are locking each other.
Ubuntu 10.10, GDB 7.2.
I attach to an application, watch stacks in every thread, everything looks good. Do generate-core-file and try to open that coredump in gdb. No routines is shown in backtraces.
I send SIGSEGV to the application and open this new coredump in gdb. Stacks are ok and verbose.
Please tell me if you experienced a similar incorrect behaviour of generate-core-file.
This is a known bug in GDB. The link has also a patch for fixing the problem.
I'm trying to generate a release build for a C++ application that I've written. The application runs fine (debug & release) when you run it from within VS2008; but when you run the executable it crashes nearly every single time.
Now, is there a hack so I can run this application as a standalone application without having to run through all of the code and finding the bug that is causing it?
Thanks in advance.
In short, no.
you will have to find the bug, if it works within VS, then I'd hazard a guess that it is a timing issue, possibly you're overwriting shared thread data, this would be less likely (though still possible to see) inside VS as its being run in a debug environment which slows it down a bit.
If you want help finding your bug, then tell us more. Otherwise, build your release with debug symbols (pdbs), install DrWatson as the system debugger and run it standalone. When it crashes DrWatson will create a minidump file, load this into WinDbg (my favourite) and you'll be able to see exactly where your bug is (it'll even tell you that the dump contains an exception and show you it by default. You need to add your source code path and path to your symbols in WinDbg to get it to do this correctly).
Then you will also know how to diagnose crashes when the app is run on-site too.
Are you loading external resources? If you are check that your relative paths are correct in the C++ program.
One possibility is that your program uses uninitialized heap data. Launching a program from the debugger enables the NT debug heap, which causes the heap allocator to fill new memory blocks with a fill pattern, and also enables some heap checking. Launching the same program from outside the debugger leaves the NT debug heap disabled, but if the program was linked against the debug version of the C runtime, then the CRT debug heap will still be enabled.
A much less likely possibility is that your program requires SeDebugPrivilege to be set in its process token. The debugger enables this privilege in its process token, which has the side effect that all programs launched from the debugger inherit this privilege. If your program tries to use OpenProcess()/ReadProcessMemory()/WriteProcessMemory() and doesn't handle errors correctly, it's conceivable that it could crash.
There are a few possibilities. Besides what has already been mentioned, running an app from Visual Studio will execute in the same security context as the Visual Studio instance. So if, for instance, you are working on Vista, you might be hitting an unhandled security violation if you're trying to access protected files, or the registry.
What if you build a debug version and run it standalone? Does it crash? If so, you can usually break into the debugger from there and get a call stack to see what the malfunction is.
From the details you've given, it sounds like there may be a library issue. Are you running the program on the same computer? If not then you'll also have to deploy the appropriate libraries for your application. If you are running on the same computer but outside of the dev environment, ensure that your application can see the appropriate libraries.
Best way i have found to debug in release is to create a crash dump when an crash happens and the dump then allows me to load debug symbols on my dev computer and find out whats going on. More info here: http://www.debuginfo.com/articles/effminidumps.html
You can also go to file => open in Visual Studio and open the .exe, so you are not starting it under the debugger per se. Not sure if it will help.
http://blogs.msdn.com/saraford/archive/2008/08/21/did-you-know-you-can-debug-an-executable-that-isn-t-a-part-of-a-visual-studio-project-without-using-tools-attach-to-process-296.aspx