Qt Creator / GDB - 调试会话意外结束 [英] Qt Creator/GDB - Debugging session ends unexpectedly

问题描述

<强> 1。症状

Qt Creator中的调试会话以随机方式意外终止（即有时会正常终止），并出现以下错误之一：

• PC寄存器不可用（最常见的错误，通常是
  内部错误：pc 0×0读入psymtab ，但不在symtab中）


• SIGSEV


• SIGILL

这将发生的第一个迹象是，当我踩到一行代码将我带到一个汇编程序窗口时，进入NTDLL（通常， ntdll！LdrFindResource_U + 60953



在Qt论坛收到的回复中，重建或Clean + Build没有对此问题有任何明显的影响。



2。首先分析

由于第一个错误是最常见的，我在网上搜索了它，这导致我这个。它看起来很重要 - 确实有一个SIGTRAP，导致了这个错误。

但是，当我检查了所有保存的调试器日志时，发现了几个场合那个错误没有发生（尽管SIGTRAP总是在那里）。

3。模式

使用WinMerge和一些耐心，我终于能够在所有错误情况下感知模式。所有的日志（错误和成功 ）都是这样的：

 > = thread-已创建，id =2，group-id =i1
 sThread 2已创建
  

它创建了第二个线程，除了我的应用程序（它在线程id =1上运行）。但是，所有成功日志都是这样的：

 > = thread-exited，id =2，group- id =i1
 s1在组1中退出
  

更多的调试会话，并在第一个断点被击中时检查正在运行的线程。在所有的错误情况下，我得到了这样的东西：

 < 455info线程
>& info thread \\\

>〜Id Target Id Frame \\\

>〜2线程7160.0x33ec 0x76f1fd71在ntdll！RtlFindSetBits（）中从C：\\ Windows \ \\ system32 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ main.cpp：10 \\\

> 455 ^ done 
  

使用Process Explorer ，我可以看到第二个线程连接到了我的可执行文件（尽管我没有创建线程，但您可以看到使用的代码）。

另外，所有的错误情况在第二个线程上都有一个SIGTRAP： / p>

 >〜[切换到线程7160.0x33ec] \\\

> * stopped，reason =信号接收的信号名称= SIGTRAP，signal-meaning =Trace / breakpoint trap，frame = {addr =0x76f1000d，func =ntdll！LdrFindResource_U，args = []，from =C：\\\\Windows \\\ system32 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\' b  

4。仔细检查GDB

要确定这是否是GDB问题，我已经运行了几个命令行调试会话，它们都带有或不带-i MI。从来没有任何引用第二线程，我从来没有意外终止调试会话，这就是为什么我相信这个问题的原因可能在Qt Creator中。

的 5。请求帮助

我已经下载了Qt Creator的源代码，并且已经在那里寻找线索，但是我并没有得到太多。 p>

gdbengine.cpp提到了一个塞线程，但我唯一发现的是 here。

任何人有任何想法/指示我应该检查什么感谢您的宝贵时间。

编辑：

我仍然没有找到原因，但在用Process Monitor查看它之后，我得到了更多的数据。

第二个线程被创建来加载我的应用程序的可执行文件和它需要的DLL。我已经证实，只有当我从Qt Creator IDE调试我的应用程序时才创建第二个线程;如果我从IDE运行它（即使用run而不是debug），或者如果我从命令行调试它（从命令行启动gdb），或者如果我从命令行运行它，这第二个线程永远不会创建，并且可执行文件+ DLL图像是由我的应用程序的主线程（也是唯一的线程）加载的。

在我上面称为成功案例 ，当第二个线程退出时，它会在加载最后一个DLL之后立即退出，这就是为什么我相信这个第二个线程只是为这个加载而创建的。

解决方案

这与任何类型的内存管理无关，而与调试器在Windows上中断进程的方式无关。检查此和此网址

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 0×0 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. I've since tested on another machine with Win732 bit, and the behaviour is the same.

Following a response I received on the Qt Forums, Rebuild or Clean + Build don't have any noticeable effect on this issue.

2. First analysis

Since the first error was the most common, I searched the web for it, which led me to this. 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).

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.

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

Thanks for your time.

EDIT:

I still haven't found the cause for this, but after looking at it with Process Monitor, I've got some more data.

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.

解决方案

This is not related to any kind of memory management, but to the way how debuggers interrupt processes on Windows. Check this and this urls

这篇关于Qt Creator / GDB - 调试会话意外结束的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！