Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QtCreator/GDB stall when breakpoint set
QtWS25 Last Chance

QtCreator/GDB stall when breakpoint set

Scheduled Pinned Locked Moved Unsolved General and Desktop
qtcreatorgdbbug
9 Posts 2 Posters 3.5k Views
  • 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.
  • S Offline
    S Offline
    StringTheory
    wrote on 10 Sept 2018, 23:02 last edited by
    #1

    Extremely odd bug: Project uses Qt and OpenCV under Linux. When a breakpoint is set immediately after one of the OpenCV statements (call to findContours, for anyone curious), QtCreator stalls. After 40 seconds or so, there is a popup saying that GDB is not responding, with a prompt asking to continue or not. Pressing 'continue' just stalls indefinitely--I've let it go for over 30 minutes with no response.

    During the stall, QtCreator's 'continue' and stop buttons are grayed out. There is no way to interact with QtCreator. The only escape is to stop the process by pressing 'no' when the initial GDB message comes up, or just aborting QtCreator.

    The odd thing: If no breakpoint is set, the program just continues and functions as expected. There seems to be something about setting the breakpoint after the call to OpenCV function, but it's difficult to get any additional clues. The function call itself is nothing unusual. Fairly generic textbook code sequence.

    I've been working with QtCreator as a dev environment for about 6 months, and this is the first that I've seen anything like this. It's difficult to say whether this is a QtCreator bug or a glitch with GDB, or a combination.

    The other odd aspect is that QtCreator provides no way to break out of the ozone loop, aside from just waiting for the GDB timeout message.

    Has anyone seen anything like this? I'm hoping it's documented behavior that can be addressed.

    1 Reply Last reply
    0
    • S Offline
      S Offline
      StringTheory
      wrote on 10 Sept 2018, 23:20 last edited by StringTheory 9 Oct 2018, 23:22
      #2

      QtCreator version is 4.5.1, with Qt version 5.10.1.

      The version is from around Feb 2018. I haven't wanted to update anything for fear of breaking running code.

      Development in C++ (GCC), under Linux Mint 18.1.

      1 Reply Last reply
      0
      • S Offline
        S Offline
        StringTheory
        wrote on 11 Sept 2018, 10:58 last edited by StringTheory 9 Nov 2018, 10:59
        #3

        OK, here is what I found. Hopefully will help those with similar problems:

        I updated Qt and QtCreator to the latest version:
        No help

        I updated GDB to v8.2, which was a pain. The normal Linux command line
        install reported that 7.11 was already the latest. Incorrect. So I had to build
        v8 from scratch which took quite a while.
        But still no help.

        Then I changed the QtCreator C++ compiler settings from GCC to Clang++.
        That seems to have done the trick.

        Still no idea why this occurred, but perhaps it was yet another GCC bug.

        We'll see if this stays fixed. This was a rather unsettling bug, since it was
        impossible to tell if it was a problem with source code, or was coming from
        QtCreator, or GDB, or the compiler. It seemed to shift around with changes
        in source, and where the breakpoint was placed.

        1 Reply Last reply
        1
        • S Offline
          S Offline
          StringTheory
          wrote on 12 Sept 2018, 13:10 last edited by
          #4

          Spoke too soon (damn!) The bug is still there, but just shifted. By that, I mean that breakpoints that are set in the places that originally caused the bug to surface now work correctly. But I just placed a breakpoint elsewhere, and the same behavior resurfaced: GDB stall, with Qt prompt to keep going or abort after 40 second timeout.

          At this point, I have to think that this is a GDB bug. It could still be something else, but when the debugger itself goes away, never to return, it points to the debugger as the culprit.

          It also seems that Qt should have a responsive button to break out of conditions like this, and perhaps some feedback about what was going on at the point of the break.

          A 1 Reply Last reply 12 Sept 2018, 16:23
          0
          • S StringTheory
            12 Sept 2018, 13:10

            Spoke too soon (damn!) The bug is still there, but just shifted. By that, I mean that breakpoints that are set in the places that originally caused the bug to surface now work correctly. But I just placed a breakpoint elsewhere, and the same behavior resurfaced: GDB stall, with Qt prompt to keep going or abort after 40 second timeout.

            At this point, I have to think that this is a GDB bug. It could still be something else, but when the debugger itself goes away, never to return, it points to the debugger as the culprit.

            It also seems that Qt should have a responsive button to break out of conditions like this, and perhaps some feedback about what was going on at the point of the break.

            A Offline
            A Offline
            aha_1980
            Lifetime Qt Champion
            wrote on 12 Sept 2018, 16:23 last edited by
            #5

            Hi @StringTheory said in QtCreator/GDB stall when breakpoint set:

            I can't remember having seen such a strange behavior. Recently I had debugged a profile build by accident - that was already strange enough. Have you checked that's not the case for you?

            At this point, I have to think that this is a GDB bug. It could still be something else, but when the debugger itself goes away, never to return, it points to the debugger as the culprit.

            Well, you could try to use GDB from the command line, but who want's that...

            It also seems that Qt should have a responsive button to break out of conditions like this, and perhaps some feedback about what was going on at the point of the break.

            Have you already had a look in the debugger log (Windows > Views > Debugger Log)?

            Regarding the button: I'm unsure if it's needed often (I guess you can stop debugging with the same consequence), but maybe the feedback could be really better.

            Regards and good luck!

            Qt has to stay free or it will die.

            S 1 Reply Last reply 13 Sept 2018, 01:59
            0
            • A aha_1980
              12 Sept 2018, 16:23

              Hi @StringTheory said in QtCreator/GDB stall when breakpoint set:

              I can't remember having seen such a strange behavior. Recently I had debugged a profile build by accident - that was already strange enough. Have you checked that's not the case for you?

              At this point, I have to think that this is a GDB bug. It could still be something else, but when the debugger itself goes away, never to return, it points to the debugger as the culprit.

              Well, you could try to use GDB from the command line, but who want's that...

              It also seems that Qt should have a responsive button to break out of conditions like this, and perhaps some feedback about what was going on at the point of the break.

              Have you already had a look in the debugger log (Windows > Views > Debugger Log)?

              Regarding the button: I'm unsure if it's needed often (I guess you can stop debugging with the same consequence), but maybe the feedback could be really better.

              Regards and good luck!

              S Offline
              S Offline
              StringTheory
              wrote on 13 Sept 2018, 01:59 last edited by
              #6

              @aha_1980 : Actually, that is very helpful; the only real clue about this so far. The relevant statements at the point where GDB stalls:


              d252: python theDumper.fetchVariables({"autoderef":1,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["return","inspect","local","watch"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","token":252,"typeformats":{},"watchers":[]})
              d253: -exec-continue
              dTIMED OUT WAITING FOR GDB REPLY. COMMANDS STILL IN PROGRESS: "-exec-continue", "python theDumper.fetchVariables({"autoderef":1,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["return","inspect","local","watch"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","token":252,"typeformats":{},"watchers":[]})"


              I'm not sure why "python theDumper" appears in a debug session for C++ code, but perhaps it's used in GDB somehow.

              1 Reply Last reply
              0
              • A Offline
                A Offline
                aha_1980
                Lifetime Qt Champion
                wrote on 13 Sept 2018, 05:56 last edited by aha_1980
                #7

                @StringTheory said in QtCreator/GDB stall when breakpoint set:

                I'm not sure why "python theDumper" appears in a debug session for C++ code, but perhaps it's used in GDB somehow.

                The python dumpers are used to show the contents of complex variables like QStringList in a human readable format.

                The questions is, if the python dumpers add some extra problems for you. That's why I suggested to try gdb from command line and break at the same position to see if its working from there.

                Qt has to stay free or it will die.

                S 2 Replies Last reply 13 Sept 2018, 07:19
                0
                • A aha_1980
                  13 Sept 2018, 05:56

                  @StringTheory said in QtCreator/GDB stall when breakpoint set:

                  I'm not sure why "python theDumper" appears in a debug session for C++ code, but perhaps it's used in GDB somehow.

                  The python dumpers are used to show the contents of complex variables like QStringList in a human readable format.

                  The questions is, if the python dumpers add some extra problems for you. That's why I suggested to try gdb from command line and break at the same position to see if its working from there.

                  S Offline
                  S Offline
                  StringTheory
                  wrote on 13 Sept 2018, 07:19 last edited by
                  #8

                  @aha_1980 : Oh, so the Python dumper message is from Qt. The log file must be a combination of Qt and GDB messages then. That sounds even more difficult to sort out.

                  I suppose I've got to get up to speed on GDB. I've never used it stand-alone, so I'll have to figure out what's required to load symbols and such.

                  That's a helpful observation. Thanks.

                  1 Reply Last reply
                  0
                  • A aha_1980
                    13 Sept 2018, 05:56

                    @StringTheory said in QtCreator/GDB stall when breakpoint set:

                    I'm not sure why "python theDumper" appears in a debug session for C++ code, but perhaps it's used in GDB somehow.

                    The python dumpers are used to show the contents of complex variables like QStringList in a human readable format.

                    The questions is, if the python dumpers add some extra problems for you. That's why I suggested to try gdb from command line and break at the same position to see if its working from there.

                    S Offline
                    S Offline
                    StringTheory
                    wrote on 13 Sept 2018, 11:19 last edited by
                    #9

                    @aha_1980 : I just noticed something else: In the log file, there are lines saying "GDB 71101", presumably because it is using v7.11.1 (?!). But I have installed GDB v8.2 in both usr/bin and usr/local/bin. And I've set those locations in QtCreator's options pages for kits and for debuggers. There should be no way for QtCreator to find an older GDB version.

                    The GDB version in both usr/ folders above is 8.2, confirmed by running via terminal. And I did not find any older stray 7.11.1 versions that QtCreator could be picking up.

                    Another oddity. Is there any other options page where the GDB location needs to be set?

                    1 Reply Last reply
                    0

                    7/9

                    13 Sept 2018, 05:56

                    • Login

                    • Login or register to search.
                    7 out of 9
                    • First post
                      7/9
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • Users
                    • Groups
                    • Search
                    • Get Qt Extensions
                    • Unsolved