Program SegFaults but doesn't give me any information
Hi there, I am currently having a problem where my program will produce a SegFault. I understand that this is normally from accessing memory that the program shouldn't be. I am currently trying to debug where the SegFault is occuring but I have a fairly large codebase, and when the QT Debugger tells me I have a SegFault, it doesn't seem to show me the stack trace anywhere to show what function caused the SegFault, nor does it break on the line that SegFaulted, as you can see here.
Is there any way for me to find out the line number or function in which the SegFault occured?
What debug information would you be expecting from a release build?
@kshegunov That's true, I didn't think about that. Unfortunately I cannot get the SegFault to occur in the Debug version, the program simply hangs and I then have to force close it after it becomes unresponsive.
EDIT: Please ignore me, it seems to give me the SegFault in the Debug Version now.
EDIT: It's back to not showing again.
Unfortunately I cannot get the SegFault to occur in the Debug version, the program simply hangs and I then have to force close it after it becomes unresponsive.
Fix that first, then try in release mode. If you're using threads, it might be the synchronization, because it sounds like a race condition happening.
@kshegunov I realised I had some extra code still running in my program that I had added and forgot to remove. Now that my code is back to the way it used to be, in Debug mode my program seems to function no problem (see below), however as soon as I run the code in Release mode it segfaults almost straight away.
There is no threading in my code at the moment.
Debug Mode - Run: Program will hang and become unresponsive
Debug Mode - Start Debugging: Program has no problems at all
Release Mode - Run: Program will crash "Program has stopped responding"
Released Mode - Start Debugging: Program SegFaults
Well, that's certainly quite strange. The only thing that I can think of currently is that some static variables are not initialized in the proper order, but still this'd be by far a long shot.
@RBrNx277 Maybe something like this one:
The problem here was the call to exit() which did not call the destructor of QApplication and since QApplication seems to do something with threads, these threads are cleaned up "somewhen". Sadly the order of the cleanup … however, it sometimes crashed. Maybe you have a similar problem.
BTW: I never have seen those crashes in Qt 4, just with Qt5
Naturally you shouldn't just terminate the process arbitrarily with exit. It's like hitting someone with a baseball bat for goodbye! Just allow the application to gracefully exit by returning the value of
QApplication::execthus allowing for the cleanup code to run. By the way you also (possibly) have a memory leak as no one is obligated to clean up your window automatically. If you want to return a specific integer to the shell, well then just call
QApplication::exitwith the appropriate code.
PS. Since you were wondering
::exit()will not clean up objects with automatic storage (i.e. stack objects), that's why the
QApplicationdestructor is not called.