Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Update: Forum Guidelines & Code of Conduct

    Unsolved Debugger doesn't show the source of the error

    Tools
    3
    11
    2161
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      Mark81 last edited by

      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?

      aha_1980 1 Reply Last reply Reply Quote 0
      • aha_1980
        aha_1980 Lifetime Qt Champion @Mark81 last edited by

        @Mark81

        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.

        Qt has to stay free or it will die.

        M 1 Reply Last reply Reply Quote 0
        • M
          Mark81 last edited by

          This post is deleted!
          1 Reply Last reply Reply Quote 0
          • M
            Mark81 @aha_1980 last edited by Mark81

            @aha_1980
            The problem is I see nothing useful in the stack view panel:

            0_1528790377701_debug.jpg

            Perhaps am I missing something in the Debugger views?

            aha_1980 1 Reply Last reply Reply Quote 0
            • aha_1980
              aha_1980 Lifetime Qt Champion @Mark81 last edited by

              @Mark81 I think you have selected the wrong thread.

              Qt has to stay free or it will die.

              1 Reply Last reply Reply Quote 0
              • M
                Mark81 last edited by

                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.

                JonB 1 Reply Last reply Reply Quote 0
                • JonB
                  JonB @Mark81 last edited by JonB

                  @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.

                  1 Reply Last reply Reply Quote 1
                  • M
                    Mark81 last edited by

                    @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!

                    JonB 1 Reply Last reply Reply Quote 0
                    • JonB
                      JonB @Mark81 last edited by

                      @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?

                      1 Reply Last reply Reply Quote 0
                      • M
                        Mark81 last edited by

                        @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.

                        JonB 1 Reply Last reply Reply Quote 0
                        • JonB
                          JonB @Mark81 last edited by JonB

                          @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?

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post