How to do or any tips on how to debug in situation like this, where C++ Qt GUI program crashes and stack has no clear reference to where the crash is coming from.
Is there some settings for QtCreator or some additional tools that could analyze the start point of the crash? I am assuming that it happens in other than main thread that causes it not to be displayed, but that is just a guess.
1 __GI_raise raise.c 51 0x7ffff2ddae87
2 __GI_abort abort.c 79 0x7ffff2ddc7f1
3 ?? 0x7ffff37cf957
4 ?? 0x7ffff37d5ae6
5 std::terminate() 0x7ffff37d5b21
6 qTerminate() 0x7ffff3d73205
7 QThreadPrivate::start(void *) 0x7ffff3d93be7
8 start_thread pthread_create.c 463 0x7ffff3ad36db
9 clone clone.S 95 0x7ffff2ebd61f
There is not any own code in stack trace and all is in dissasembled form.
I was expecting stacktrace to have startpoint to my own code where the crash started, but there is only library and system code.
The “4 ??” stack has some hints about the crash being pointer error, but I am not sure:
Thanks to @AlanBirtles, I also found the application output of the error, that might help me further.
Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
If that is not possible, in Qt 5 you must at least reimplement
QCoreApplication::notify() and catch all exceptions there.
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Thank You.
2
The tool is called debugger and there is one in the QtCreator. Generally you start with what action triggers the crash, and then you can step by step follow code execution within this action until the crash happens so that you know which line is the last to be executed. Mind that it may not be the line causing the crash, especially when it’s a pointer problem. However, the last line is probably the line that is doing something with the pointer. If you identified which pointer it is, you can now trace its usage across the program.
Easier way is to just start the debug and it should stop when the crash happens and give you the full trace. But that might not be the case. If you’re using multithreading, look for race conditions as well.
It’s generally not a good idea to have raw pointers at all.