1. Accueil
  2. Question et réponse
  3. *** *** glibc détectée double libération ou de corruption (fasttop):

*** *** glibc détectée double libération ou de corruption (fasttop):

2010-02-04 3 views
3

Un appel à effacer sur un QByteArray génère l'exception suivante:*** *** glibc détectée double libération ou de corruption (fasttop):

* glibc détecté */home/yan/FPS2/FPS2: double gratuit ou corruption (fasttop):

0 ?? 1 ??

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

est-ce un bug qt ou pourrait-il avoir quelque chose à voir avec mon code? Je connais QObjects arent thread safe (définition QT pas plusieurs threads appelant la même fonction de la même instance d'objet) mais ma fonction a mutexes. Aussi, je reçois très rarement cette erreur même si la même fonction est appelée fréquemment. P.S. Une façon d'éviter cela est d'env var MALLOC_CHECK_ 0

cette URL concerne un problème similaire et certains messages semblent impliquer son causé par une version incompatible de la glibc.

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

Source

2010-02-04 yan bellavance

+1

Les trois dernières questions que vous avez postées semblent être des symptômes de synchronisation incorrecte entre les threads. Je ne pense pas que votre classe FPSengine soit thread safe, mais il n'y a toujours pas assez d'informations pour fournir une réponse. – rpg

+0

Eh bien, j'ai fait un test en n'activant que l'un des qthreads et bien sûr le thread principal est toujours là. Aussi le thread principal ne faisait rien et la fonction appelée depuis le qthread a un verrouillage mutex sur la première instruction et le déverrouillage sur la dernière instruction. D'après ce que je peux voir en lisant le code de la documentation QByteArray.cpp et Qt sur les classes implicitement partagées, cela semble être un problème de déréférencement. Maintenant, j'essaie de voir comment la synchronisation des threads son impliqué –

Répondre

1

cela est dû au fait que l'application est multithread, l'objet appartient au thread principal mais est utilisé dans un autre thread, même si j'ai utilisé des mutex sur le QBytearray le UDPsocket qui l'utilise readDatagram est aussi dans le thread principal ... et oui j'ai besoin que udpSocket soit aussi dans le fil principal

Source

2010-02-26 01:02:24

4

Il pourrait y avoir un certain nombre de choses, y compris le référencement d'un QByteArray temporaire retourné par un appel de fonction, mais il est peu probable (OMI) à un bogue dans Qt.

est ici quelques réflexions pour le débogage:

  • exécuter sous Valgrind et voir si elle mettra en évidence le problème
  • exécuter votre application avec une version de Qt qui a des symboles de débogage disponibles pour ce
  • activer les vidages de base et voir si vous obtenez un fichier de base

Source

2010-02-04 05:44:04

1

Je doute fortement que vous ayez trouvé un bug dans qt. Cette erreur peut survenir pour un certain nombre de raisons, mais essentielle signifie que vous avez une référence à la mémoire qui a déjà été libérée. Exécutez les débogueurs et essayez de voir ce qui cause le problème. Utilisez gdb et valgrind et espérons que vous pourrez trouver le problème.

Source

2010-02-04 05:45:43 captncraig

Questions connexes

 Questions connexes