Qt Creator/GDB - Debugging session ends unexpectedly



  • Hallo.

    1. The symptoms
    Debugging sessions in Qt Creator terminate unexpectedly, in a random fashion (i.e., sometimes they terminate normally), with one of the following errors:

    • PC register is not available (the most common error, usually with "Internal error: pc 0x0 in read in psymtab, but not in symtab")
    • SIGSEV
    • SIGILL

    The first sign that this is going to happen is when stepping on a line of my code takes me to an assembler window, into NTDLL (usually, ntdll!LdrFindResource_U+60953).

    I'm running Qt Creator 2.6.2 with Qt 5.0.1, using QT Creator's MinGW (32 bit), on Win7 64.

    2. First analysis
    Since the first error was the most common, I searched the web for it, which led me to "this":http://sourceware.org/bugzilla/show_bug.cgi?id=14018. It seemed spot on - there was definitely a SIGTRAP, which led to that error.

    However, as I double-checked all my saved debugger logs, I found several occasions where that error didn't happen (although the SIGTRAP was always there).

    3. The pattern
    Armed with WinMerge and some patience, I was finally able to perceive a pattern in all the error cases. All the logs (both error and success) had something like this:

    @>=thread-created,id="2",group-id="i1"
    sThread 2 created
    @

    which created a 2nd thread, in addition to my app (which was running on thread id="1"). However, all the success logs had something like this:

    @>=thread-exited,id="2",group-id="i1"
    sThread 2 in group i1 exited
    @

    So, I ran a few more more debugging sessions, and checked the running threads when the first breakpoint was hit. On all the error cases, I was getting something like this:

    @<455info threads

    &"info threads\n"
    ~" Id Target Id Frame \n"
    ~" 2 Thread 7160.0x33ec 0x76f1fd71 in ntdll!RtlFindSetBits () from C:\Windows\system32\ntdll.dll\n"
    ~"* 1 Thread 7160.0x128c main (argc=1, argv=0xbb30d8) at ..\Exeample\main.cpp:10\n"
    455^done
    @

    Using Process Explorer, I could see that this second thread was attached to my executable (even though I don't create threads, you can see the used code "here":http://stackoverflow.com/questions/12186963/qt-string-builder-in-for-loop/12187166#12187166).

    Also, all the error cases had a SIGTRAP on that second thread:

    @>~"[Switching to Thread 7160.0x33ec]\n"

    *stopped,reason="signal-received",signal-name="SIGTRAP",signal-meaning="Trace/breakpoint trap",frame={addr="0x76f1000d",func="ntdll!LdrFindResource_U",args=[],from="C:\\Windows\\system32\\ntdll.dll"},thread-id="2",stopped-threads="all"
    dNOTE: INFERIOR SPONTANEOUS STOP
    @

    4. Double-check GDB
    To determine if this was a GDB issue, I've run several command-line debugging sessions, both with and without "-i mi". There never was any reference to a 2nd thread, and I never had a debugging session terminate unexpectedly, which is why I believe the cause for this issue could be in Qt Creator.

    5. Request for help
    I've downloaded Qt Creator's source, and I've looked for clues there, but I didn't get very far.

    gdbengine.cpp mentions a "stopper thread", but the only mention I've found is "here":http://www.qtcentre.org/threads/43833-GDB-Cannot-Remove-Internal-Breakpoint.

    Anyone has any idea/pointer about what I should check next?

    Thanks for your time.


  • Moderators

    Does doing a clean rebuild help? Are all your libs built with the same compiler?



  • [quote author="Tobias Hunger" date="1363704438"]
    Does doing a clean rebuild help?
    [/quote]

    At first, it seemed so. I did 10 runs with no rebuild, and got 9 "failures" (two threads, stepping took me into ntdll and eventually finished the session with a SIGSEV).

    Then I did another 20 with several combinations of Rebuild and Clean + Build, and I got 50/50.

    But then I did another 10 runs with no build/rebuild, and I got 7 successes (all with 1 thread) and 3 SIGSEV failures (all with 2 threads).

    [quote author="Tobias Hunger" date="1363704438"]
    Are all your libs built with the same compiler?[/quote]

    For this test I'm only using Qt. This is what I have:
    Compiler: C:\Dev\Qt\Qt5.0.1\Tools\MinGW\bin\g++.exe (ABI: x86-windows-msys-pe-32bit)
    Qt Version: Qt 5.0.1 MinGW 32 bit (auto-detected); qmake location: C:\Dev\Qt\Qt5.0.1\5.0.1\mingw47_32\bin\qmake.exe
    Kit: Uses the above compiler/Qt; Debugger: GDB Engine using "C:\Dev\Qt\Qt5.0.1\Tools\MinGW\bin\gdb.exe"

    All this was installed with Qt Creator 2.6.2.

    I have another version of Qt (4.8.2). I also have mingw.org's MinGW, and MSVC, and I have Qt and other libs (e.g., Boost, POCO) built for each of these, but they're not on the PATH for this example.

    Build path:
    C:\Dev\Qt\Qt5.0.1\5.0.1\mingw47_32\bin
    C:\Dev\Qt\Qt5.0.1\Tools\MinGW\bin
    C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
    C:\Windows\system32
    C:\Windows
    C:\Windows\System32\Wbem
    C:\Windows\System32\WindowsPowerShell\v1.0
    C:\Dev\perl\sberry\perl\site\bin
    C:\Dev\perl\sberry\perl\bin
    C:\Dev\Python
    C:\Dev\Ruby\Ruby193\bin
    C:\Program Files\TortoiseGit\bin
    C:\Dev\msysgit\msysgit\bin
    C:\Dev\msysgit\msysgit\git
    C:\Dev\tools\msmtp\msmtp-1.4.28-w32
    C:\Dev\GtkSharp\2.12\bin
    C:\Program Files (x86)\GnuWin32\bin
    C:\Program Files\doxygen\bin
    C:\Program Files (x86)\Nmap
    C:\Program Files (x86)\Graphviz 2.28\bin
    C:\Program Files (x86)\QuickTime\QTSystem
    C:\Program Files\Microsoft SQL Server\110\Tools\Binn\

    Run path:
    C:\Dev\Qt\Qt5.0.1\5.0.1\mingw47_32\lib
    C:\Dev\Qt\Qt5.0.1\5.0.1\mingw47_32\bin
    C:\Dev\Qt\Qt5.0.1\Tools\MinGW\bin
    C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
    C:\Windows\system32
    C:\Windows
    C:\Windows\System32\Wbem
    C:\Windows\System32\WindowsPowerShell\v1.0
    C:\Dev\perl\sberry\perl\site\bin
    C:\Dev\perl\sberry\perl\bin
    C:\Dev\Python
    C:\Dev\Ruby\Ruby193\bin
    C:\Program Files\TortoiseGit\bin
    C:\Dev\msysgit\msysgit\bin
    C:\Dev\msysgit\msysgit\git
    C:\Dev\tools\msmtp\msmtp-1.4.28-w32
    C:\Dev\GtkSharp\2.12\bin
    C:\Program Files (x86)\GnuWin32\bin
    C:\Program Files\doxygen\bin
    C:\Program Files (x86)\Nmap
    C:\Program Files (x86)\Graphviz 2.28\bin
    C:\Program Files (x86)\QuickTime\QTSystem
    C:\Program Files\Microsoft SQL Server\110\Tools\Binn\

    Anyway, I reduced the paths to these below and ran some more debugging sessions, but I still got the same behaviour:
    Build Path: C:\Dev\Qt\Qt5.0.1\5.0.1\mingw47_32\bin;C:\Dev\Qt\Qt5.0.1\Tools\MinGW\bin
    Run Path: C:\Dev\Qt\Qt5.0.1\5.0.1\mingw47_32\lib;C:\Dev\Qt\Qt5.0.1\5.0.1\mingw47_32\bin;C:\Dev\Qt\Qt5.0.1\Tools\MinGW\bin

    Once again, thanks for your time, this doesn't seem to have a simple answer.



  • Maybe related (and indicating this is not a Qt Creator problem) : https://sourceware.org/ml/gdb-patches/2014-03/msg00621.html



  • [quote author="andrep" date="1395863242"]Maybe related (and indicating this is not a Qt Creator problem) : https://sourceware.org/ml/gdb-patches/2014-03/msg00621.html[/quote]

    I've actually got a bit more data on this (posted it "here":http://stackoverflow.com/questions/15550265/qt-creator-gdb-debugging-session-ends-unexpectedly), namely:

    bq. The second thread is created to load my app's executable and the DLLs it requires. I've confirmed this second thread is created only when I debug my app from the Qt Creator IDE; if I run it from the IDE (i.e., use "run" instead of "debug"), or if I debug it from the command line (launch gdb from the command line), or if I run it from the command line, this second thread is never created, and the executable + DLL images are loaded by my app's main (and only) thread. On what I called "success cases" above, i.e., when this second thread exits, it exits immediately after loading the last DLL, which is why I believe this second thread is created only for this loading.

    Whatever is going on here, it still happens with Qt Creator 2.8.1.

    The reason why I think this is related to Qt Creator is that this second thread isn't spawned when I launch a debug session with dbg from the command line, only when I debug from the IDE.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.