views:

1519

answers:

3

A call to clear on a QByteArray generates the following exception:

* glibc detected * /home/yan/FPS2/FPS2: double free or corruption (fasttop):

0 ?? 1 ??
2 free
3 QByteArray::clear()
4 FPSengine::getDatagrams
5 FPSengine::xmitData
6 FPSengine::getData
7 threadDatalog::run
8 ??
9 start_thread
10 clone
11 ?? 0

is this a qt bug or could it have something to do with my code? I know QObjects arent thread safe (QT definition not multiple threads calling the same function of the same object instance)but my function has mutexes. Also I very rarely get this error even though the same function is called frequently. P.S. A way to prevent this is to env var MALLOC_CHECK_ 0

this url relates a similar problem and some posts seems to imply its caused by an incompatible version of glibc.

http://stackoverflow.com/questions/882422/glibc-detected-perl-double-free-or-corruption-prev-0x0c2b7138

+2  A: 

It could be a number of different things, including referencing a temporary QByteArray returned by a function call, but it's unlikely (IMO) to be a bug in Qt.

Here's a few thoughts for debugging:

  • run it under Valgrind and see if it will highlight the problem
  • run your application against a version of Qt that has debug symbols available for it
  • enable core dumps and see if you get a core file
Kaleb Pederson
+1  A: 

I highly doubt you have found a bug in qt. That error can occur for a number of reasons, but essential means you have a reference to memory that has already been freed. Run through debuggers and try and see what is causing the problem. Use gdb and valgrind and hopefully you can track down the problem.

CaptnCraig
A: 

this is caused by the fact the the application is multithreaded, the object belongs in the mainthread but is used in another thread, even though I used mutexes on the QBytearray the UDPsocket which uses it to do readDatagram is also in the mainthread...and yes I need that udpSocket to be in the main thread as well

yan bellavance