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.
-
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\binOnce 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.