Unsolved Debugger doesn't show the source of the error
-
Using QtCreator 4.6.1 under Linux, I'm trying to debug my application. There's a bug when I try to access a QList:
ASSERT failure in QList<T>::operator[]: "index out of range", file ../../../../opt/qt5pi/include/QtCore/qlist.h, line 549 ../../../../opt/qt5pi/include/QtCore/qlist.h: 549
but it doesn't report my line of code where the exception was generated.
In debug mode, when the error happens it stops and show a dialog window:Signal Received: the inferior stopped because it received a signal from the operating system. Signal name: SIGABRT, Signal meaning: Aborted.
After clicked ok I should be able to inspect the offensive line of code. But it shows just disassembled code! The current thread is set to my application (compiled in debug mode).
I don't understand how to retrieve the source of such an error. I need to set something in the project's options?
-
Of course the error is raised in Qt's code - there is no other way to do it in C++. If you had the sources installed, you would see the QList source code.
But just use the debuggers stack view to go to your app level to see where your code got it wrong.
-
This post is deleted! -
@aha_1980
The problem is I see nothing useful in the stack view panel:
Perhaps am I missing something in the Debugger views?
-
@Mark81 I think you have selected the wrong thread.
-
I think it's the thread of my application (called "Bub"), the others available are:
- #2 QQmlDebugServer
- #3 QQmlThread
- #4 VCHIQ completio
- #5 HDispmanx Notif
- #6 HTV Notify
- #7 HCEC Notify
- #8 QThread
- #9 QSGRenderThread
I checked all of them and they only show disassembled code for each item in the call stack. I see no code of my application.
-
@Mark81
Just to be clear: you will not always find that an error is called directly from your code or will show a stack trace into your code. It may be that the assertion code is being called directly from Qt, as in (indirect) consequence of something your code previously did. For example, the fault may arise when Qt next gets to process the main event loop and act on anything pending. It doesn't make debugging any easier, but there you are!When it asserts in Qt code, you will only see assembler, unless you compiled Qt with debug and the debugger can find the corresponding source code file.
-
@JonB so, what do you recommend to find out my mistake? Of course I can do the old-dirty way to put debug messages here and there or to comment different pieces of code and see what happens... but it's very time-consuming! I would hope in 2018 we have better tools to debug applications!
-
@Mark81
We do have tools to debug applications: if you need a traceback from Qt code, I have suggested start by compiling Qt for debug and allow the debugger to find the source code file.... Are you already compiling Qt yourself, or are you using a fetched, pre-compiled version? -
@JonB sorry, I didn't understand what you said. I understood if I compiled Qt in debug mode the debugger will show the Qt source code that would be unuseful. I cross-compiled them by myself for Raspberry Pi 3 with Linaro toolchain.
-
@Mark81 said in Debugger doesn't show the source of the error:
I understood if I compiled Qt in debug mode the debugger will show the Qt source code that would be unuseful.
As I said, if it is the case that the fault is coming as a result of Qt code executed internally as an indirect consequence of something your code did earlier, what else do you expect to get out of a debugger? Yes, it will show the Qt code. Then in the debugger you can try to understand which list of yours is being accessed.
P.S.
I don't do cross-compilation, but I presume the way it works is that you are running a native debugger on the target machine (RPi). Are you sure that the source file paths are available to & valid paths from the target's POV?
