*** glibc的检测***双重释放或腐败（fasttop）：
呼叫清除在QByteArray中生成以下异常：*** glibc的检测***双重释放或腐败（fasttop）：
* glibc的检测* /家庭/燕/ FPS2/FPS2：双重免费或腐败（fasttop）：
0 ?? 1 ??
2*
3的QByteArray ::明确（）
4 FPSengine :: getDatagrams
5 FPSengine :: xmitData
6 FPSengine ::的getData
7 threadDatalog ::运行
8 ??
9 start_thread
10克隆
11 ?? 0
这是一个QT错误，或者它可能与我的代码有关吗？我知道QObject不是线程安全的（QT定义不是多线程调用同一个对象实例的同一个函数），但我的函数具有互斥体。即使经常调用相同的函数，我也很少发生这个错误。附：防止这种情况的一种方法是env var MALLOC_CHECK_ 0
这个URL涉及到一个类似的问题，一些帖子似乎暗示它是由一个不兼容的glibc版本引起的。
*** glibc detected *** perl: double free or corruption (!prev): 0x0c2b7138 ***
这是由于应用程序是多线程的，该对象属于mainthread，但在另一个线程中使用，即使我在QBytearray上使用了互斥锁，使用它执行readDatagram的UDPsocket也位于主线程中...是的我需要udpSocket也在主线程
这可能是许多不同的东西，包括引用由函数调用返回的临时QByteArray，但它不太可能（IMO）是在Qt的一个bug。
下面是一个用于调试的一些想法：
- 来看，它Valgrind的下，看看它是否会突出问题
- 运行对一个版本的Qt的具有可它
- 调试符号的应用启用核心转储，看看你是否得到一个核心文件
我非常怀疑你已经发现了一个在qt中的错误。出现这种错误的原因可能有很多，但基本意味着您需要引用已释放的内存。运行调试器并尝试查看导致问题的原因。使用gdb和valgrind，希望你可以追踪到这个问题。
您发布的最后三个问题似乎是线程之间不正确同步的症状。我不认为你的FPSengine类是线程安全的，但是仍然没有足够的信息来提供答案。 – rpg 2010-02-04 10:06:32
好吧，我做了一个测试，只启用了一个qthreads，当然mainthread总是在那里。另外主线程没有做任何事情，从qthread调用的函数在第一条指令上有一个互斥锁定，并在最后一条指令上解锁。从阅读QByteArray.cpp代码和隐式共享类的Qt文档可以看出，这似乎是一个解引用问题。现在我正试图看看他涉及的线程同步 – 2010-02-04 17:41:11