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.

*** glibc detected *** perl: double free or corruption (!prev): 0x0c2b7138 ***

Community
  • 1
  • 1
yan bellavance
  • 4,710
  • 20
  • 62
  • 93
  • 1
    The last three questions you have posted seem to be symptoms of improper synchronization between threads. I don't think that your FPSengine class is thread safe, but there still isn't enough information to provide an answer. – rpg Feb 04 '10 at 10:06
  • well I made a test by only enabling one of the qthreads and of course the mainthread is always there. Also the main thread wasnt doing anything and the function called from the qthread has a mutex locking on the first instruction and unlocking on the last instruction. From what I can see from reading the code of QByteArray.cpp and Qt documentation on implicitly shared classes this seems to be a dereferencing problem. Now I am trying to see how thread synchronization his involved – yan bellavance Feb 04 '10 at 17:41
  • Possible duplicate of [How to track down a "double free or corruption" error](https://stackoverflow.com/questions/2902064/how-to-track-down-a-double-free-or-corruption-error) – Raedwald Dec 06 '18 at 13:31

3 Answers3

4

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
  • 45,767
  • 19
  • 102
  • 147
2

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
  • 4,710
  • 20
  • 62
  • 93
1

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
  • 22,118
  • 17
  • 108
  • 151