Qt ne libère pas correctement la mémoire ?

Version imprimable

Bonjour,
Lorsque j'exécute le programme très simple suivant :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
#include <iostream>
#include <QUdpSocket>
#include <QHostAddress>
 
using namespace std;
 
int main(int argc, char *argv[])
{
  QUdpSocket  *socket = new QUdpSocket();
  delete(socket);
  return 0;
}

ou bien le programme suivant :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
#include <iostream>
#include <QUdpSocket>
#include <QHostAddress>
 
using namespace std;
 
int main(int argc, char *argv[])
{
  QUdpSocket  socket;
  return 0;
}

et que je regarde les fuites de mémoires avec valgrind, il y a apparement de la mémoire non libérée:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
chris@chris-laptop:~/Bureau/qt$ valgrind --leak-check=yes ./qt
==2161== Memcheck, a memory error detector
==2161== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2161== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==2161== Command: ./qt
==2161== 
==2161== 
==2161==  HEAP SUMMARY:
==2161==     in use at exit: 1,184 bytes in 10 blocks
==2161==   total heap usage: 61 allocs, 51 frees, 4,706 bytes allocated
==2161== 
==2161== LEAK SUMMARY:
==2161==    definitely lost: 0 bytes in 0 blocks
==2161==    indirectly lost: 0 bytes in 0 blocks
==2161==      possibly lost: 0 bytes in 0 blocks
==2161==    still reachable: 1,184 bytes in 10 blocks
==2161==         suppressed: 0 bytes in 0 blocks
==2161== Reachable blocks (those to which a pointer was found) are not shown.
==2161== To see them, rerun with: --leak-check=full --show-reachable=yes
==2161== 
==2161== For counts of detected and suppressed errors, rerun with: -v
==2161== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 67 from 8)

Le détail des blocs non libérés est

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
 
chris@chris-laptop:~/Bureau/qt$ valgrind --leak-check=full --show-reachable=yes ./qt
==2164== Memcheck, a memory error detector
==2164== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2164== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==2164== Command: ./qt
==2164== 
==2164== 
==2164== HEAP SUMMARY:
==2164==     in use at exit: 1,184 bytes in 10 blocks
==2164==   total heap usage: 61 allocs, 51 frees, 4,706 bytes allocated
==2164== 
==2164== 4 bytes in 1 blocks are still reachable in loss record 1 of 10
==2164==    at 0x4025390: operator new(unsigned int) (vg_replace_malloc.c:214)
==2164==    by 0x4C1478B: QMutexPool::get(void const*) (qmutexpool.cpp:137)
==2164==    by 0x4D25BB7: signalSlotLock(QObject const*) (qobject.cpp:112)
==2164==    by 0x4D2C81A: QObject::~QObject() (qobject.cpp:892)
==2164==    by 0x4CA71C7: QIODevice::~QIODevice() (qiodevice.cpp:405)
==2164==    by 0x4B68941: QAbstractSocket::~QAbstractSocket() (qabstractsocket.cpp:1260)
==2164==    by 0x4B6D1FC: QUdpSocket::~QUdpSocket() (qudpsocket.cpp:224)
==2164==    by 0x80488B3: main (in /home/chris/Bureau/qt/qt)
==2164== 
==2164== 8 bytes in 1 blocks are still reachable in loss record 2 of 10
==2164==    at 0x4025390: operator new(unsigned int) (vg_replace_malloc.c:214)
==2164==    by 0x4C1831D: QThreadData::current() (qthread_unix.cpp:151)
==2164==    by 0x4D2AB26: QObject::QObject(QObjectPrivate&, QObject*) (qobject.cpp:799)
==2164==    by 0x4CA728F: QIODevice::QIODevice(QIODevicePrivate&, QObject*) (qiodevice.cpp:391)
==2164==    by 0x4B6415F: QAbstractSocket::QAbstractSocket(QAbstractSocket::SocketType, QAbstractSocketPrivate&, QObject*) (qabstractsocket.cpp:1222)
==2164==    by 0x4B6D26E: QUdpSocket::QUdpSocket(QObject*) (qudpsocket.cpp:212)
==2164==    by 0x80488A7: main (in /home/chris/Bureau/qt/qt)
==2164== 
==2164== 56 bytes in 1 blocks are still reachable in loss record 3 of 10
==2164==    at 0x4025390: operator new(unsigned int) (vg_replace_malloc.c:214)
==2164==    by 0x4C182EB: QThreadData::current() (qthread_unix.cpp:148)
==2164==    by 0x4D2AB26: QObject::QObject(QObjectPrivate&, QObject*) (qobject.cpp:799)
==2164==    by 0x4CA728F: QIODevice::QIODevice(QIODevicePrivate&, QObject*) (qiodevice.cpp:391)
==2164==    by 0x4B6415F: QAbstractSocket::QAbstractSocket(QAbstractSocket::SocketType, QAbstractSocketPrivate&, QObject*) (qabstractsocket.cpp:1222)
==2164==    by 0x4B6D26E: QUdpSocket::QUdpSocket(QObject*) (qudpsocket.cpp:212)
==2164==    by 0x80488A7: main (in /home/chris/Bureau/qt/qt)
==2164== 
==2164== 80 bytes in 1 blocks are still reachable in loss record 4 of 10
==2164==    at 0x4025390: operator new(unsigned int) (vg_replace_malloc.c:214)
==2164==    by 0x4C19381: QWaitCondition::QWaitCondition() (qwaitcondition_unix.cpp:116)
==2164==    by 0x4C15DAF: QThreadPrivate::QThreadPrivate(QThreadData*) (qthread.cpp:177)
==2164==    by 0x4C15FA9: QAdoptedThread::QAdoptedThread(QThreadData*) (qthread.cpp:137)
==2164==    by 0x4C1832C: QThreadData::current() (qthread_unix.cpp:151)
==2164==    by 0x4D2AB26: QObject::QObject(QObjectPrivate&, QObject*) (qobject.cpp:799)
==2164==    by 0x4CA728F: QIODevice::QIODevice(QIODevicePrivate&, QObject*) (qiodevice.cpp:391)
==2164==    by 0x4B6415F: QAbstractSocket::QAbstractSocket(QAbstractSocket::SocketType, QAbstractSocketPrivate&, QObject*) (qabstractsocket.cpp:1222)
==2164==    by 0x4B6D26E: QUdpSocket::QUdpSocket(QObject*) (qudpsocket.cpp:212)
==2164==    by 0x80488A7: main (in /home/chris/Bureau/qt/qt)
==2164== 
==2164== 96 bytes in 1 blocks are still reachable in loss record 5 of 10
==2164==    at 0x4025390: operator new(unsigned int) (vg_replace_malloc.c:214)
==2164==    by 0x4C131B2: QMutex::QMutex(QMutex::RecursionMode) (qmutex.cpp:123)
==2164==    by 0x4C15CD0: QThreadData::QThreadData(int) (qthread_p.h:110)
==2164==    by 0x4C182FF: QThreadData::current() (qthread_unix.cpp:148)
==2164==    by 0x4D2AB26: QObject::QObject(QObjectPrivate&, QObject*) (qobject.cpp:799)
==2164==    by 0x4CA728F: QIODevice::QIODevice(QIODevicePrivate&, QObject*) (qiodevice.cpp:391)
==2164==    by 0x4B6415F: QAbstractSocket::QAbstractSocket(QAbstractSocket::SocketType, QAbstractSocketPrivate&, QObject*) (qabstractsocket.cpp:1222)
==2164==    by 0x4B6D26E: QUdpSocket::QUdpSocket(QObject*) (qudpsocket.cpp:212)
==2164==    by 0x80488A7: main (in /home/chris/Bureau/qt/qt)
==2164== 
==2164== 96 bytes in 1 blocks are still reachable in loss record 6 of 10
==2164==    at 0x4025390: operator new(unsigned int) (vg_replace_malloc.c:214)
==2164==    by 0x4C131B2: QMutex::QMutex(QMutex::RecursionMode) (qmutex.cpp:123)
==2164==    by 0x4C15CF0: QThreadData::QThreadData(int) (qthread.cpp:81)
==2164==    by 0x4C182FF: QThreadData::current() (qthread_unix.cpp:148)
==2164==    by 0x4D2AB26: QObject::QObject(QObjectPrivate&, QObject*) (qobject.cpp:799)
==2164==    by 0x4CA728F: QIODevice::QIODevice(QIODevicePrivate&, QObject*) (qiodevice.cpp:391)
==2164==    by 0x4B6415F: QAbstractSocket::QAbstractSocket(QAbstractSocket::SocketType, QAbstractSocketPrivate&, QObject*) (qabstractsocket.cpp:1222)
==2164==    by 0x4B6D26E: QUdpSocket::QUdpSocket(QObject*) (qudpsocket.cpp:212)
==2164==    by 0x80488A7: main (in /home/chris/Bureau/qt/qt)
==2164== 
==2164== 96 bytes in 1 blocks are still reachable in loss record 7 of 10
==2164==    at 0x4025390: operator new(unsigned int) (vg_replace_malloc.c:214)
==2164==    by 0x4C131B2: QMutex::QMutex(QMutex::RecursionMode) (qmutex.cpp:123)
==2164==    by 0x4C15D8A: QThreadPrivate::QThreadPrivate(QThreadData*) (qthread.cpp:177)
==2164==    by 0x4C15FA9: QAdoptedThread::QAdoptedThread(QThreadData*) (qthread.cpp:137)
==2164==    by 0x4C1832C: QThreadData::current() (qthread_unix.cpp:151)
==2164==    by 0x4D2AB26: QObject::QObject(QObjectPrivate&, QObject*) (qobject.cpp:799)
==2164==    by 0x4CA728F: QIODevice::QIODevice(QIODevicePrivate&, QObject*) (qiodevice.cpp:391)
==2164==    by 0x4B6415F: QAbstractSocket::QAbstractSocket(QAbstractSocket::SocketType, QAbstractSocketPrivate&, QObject*) (qabstractsocket.cpp:1222)
==2164==    by 0x4B6D26E: QUdpSocket::QUdpSocket(QObject*) (qudpsocket.cpp:212)
==2164==    by 0x80488A7: main (in /home/chris/Bureau/qt/qt)
==2164== 
==2164== 96 bytes in 1 blocks are still reachable in loss record 8 of 10
==2164==    at 0x4025390: operator new(unsigned int) (vg_replace_malloc.c:214)
==2164==    by 0x4C131B2: QMutex::QMutex(QMutex::RecursionMode) (qmutex.cpp:123)
==2164==    by 0x4C147A3: QMutexPool::get(void const*) (qmutexpool.cpp:137)
==2164==    by 0x4D25BB7: signalSlotLock(QObject const*) (qobject.cpp:112)
==2164==    by 0x4D2C81A: QObject::~QObject() (qobject.cpp:892)
==2164==    by 0x4CA71C7: QIODevice::~QIODevice() (qiodevice.cpp:405)
==2164==    by 0x4B68941: QAbstractSocket::~QAbstractSocket() (qabstractsocket.cpp:1260)
==2164==    by 0x4B6D1FC: QUdpSocket::~QUdpSocket() (qudpsocket.cpp:224)
==2164==    by 0x80488B3: main (in /home/chris/Bureau/qt/qt)
==2164== 
==2164== 108 bytes in 1 blocks are still reachable in loss record 9 of 10
==2164==    at 0x4025390: operator new(unsigned int) (vg_replace_malloc.c:214)
==2164==    by 0x4C15F98: QAdoptedThread::QAdoptedThread(QThreadData*) (qthread.cpp:137)
==2164==    by 0x4C1832C: QThreadData::current() (qthread_unix.cpp:151)
==2164==    by 0x4D2AB26: QObject::QObject(QObjectPrivate&, QObject*) (qobject.cpp:799)
==2164==    by 0x4CA728F: QIODevice::QIODevice(QIODevicePrivate&, QObject*) (qiodevice.cpp:391)
==2164==    by 0x4B6415F: QAbstractSocket::QAbstractSocket(QAbstractSocket::SocketType, QAbstractSocketPrivate&, QObject*) (qabstractsocket.cpp:1222)
==2164==    by 0x4B6D26E: QUdpSocket::QUdpSocket(QObject*) (qudpsocket.cpp:212)
==2164==    by 0x80488A7: main (in /home/chris/Bureau/qt/qt)
==2164== 
==2164== 544 bytes in 1 blocks are still reachable in loss record 10 of 10
==2164==    at 0x4025390: operator new(unsigned int) (vg_replace_malloc.c:214)
==2164==    by 0x4D25BD3: signalSlotLock(QObject const*) (qobject.cpp:107)
==2164==    by 0x4D2C81A: QObject::~QObject() (qobject.cpp:892)
==2164==    by 0x4CA71C7: QIODevice::~QIODevice() (qiodevice.cpp:405)
==2164==    by 0x4B68941: QAbstractSocket::~QAbstractSocket() (qabstractsocket.cpp:1260)
==2164==    by 0x4B6D1FC: QUdpSocket::~QUdpSocket() (qudpsocket.cpp:224)
==2164==    by 0x80488B3: main (in /home/chris/Bureau/qt/qt)
==2164== 
==2164== LEAK SUMMARY:
==2164==    definitely lost: 0 bytes in 0 blocks
==2164==    indirectly lost: 0 bytes in 0 blocks
==2164==      possibly lost: 0 bytes in 0 blocks
==2164==    still reachable: 1,184 bytes in 10 blocks
==2164==         suppressed: 0 bytes in 0 blocks
==2164== 
==2164== For counts of detected and suppressed errors, rerun with: -v
==2164== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 67 from 8)

Comment cela se fait-il ? Constater ca me rebute pas mal à utiliser Qt.... Si rien qu'en créant un objet la mémoire n'est pas correctement libéré, j'ai peur de ce qu'il pourrait se passer sur une grosse application....
Merci pour votre aide.

02/07/2010, 09h57
gbdivers

Bonjour

Sur quelle version de Qt travaillez vous ?

C'est peut être un problème de lib externe (par exemple, sous linux, Qt provoquait systématiquement un problème avec GTK, mais en fait, ce n'était qu'un "faux" warning). Il n'y peut être pas de fuite.

Il faudrait envoyer un bugreport (http://qt.nokia.com/developer/bugreport-form/)
02/07/2010, 10h33
atmakefka

Bonjour,
Je travaille avec la version 4.6 de Qt, sous Linux (Ubuntu).
Quelqu'un pourrait tester ce cas pour voir si cela vient de moi ou pas ?
Il faut juste rajouter le module network pour la compilation (QT += network)
Merci
02/07/2010, 10h40
gbdivers
J'ai testé sous linux (ubuntu 10.4 64b Qt 4.7) et j'ai les mêmes messages.
Désolé de ne pas pouvoir t'aider plus.

En fait, après une petite recherche sur internet ("valgrind qt"), j'ai trouvé quelques messages concernant ce problème, en particulier celui-ci :
http://stackoverflow.com/questions/1...algrind-and-qt

En fait, ça ne serait pas de "vraie" fuite mémoire mais une limitation des débuggers qui ne peuvent correctement détecter certaine désallocation.

En fait, ce qui est réellement intéressant, c'est de savoir s'il y a de "vraies" fuites mémoire, c'est à dire si tu crées beaucoup de QUdpSocket et que tu les libères, est-ce que ta mémoire va saturer un moment donné (et qu'il faudra relancer le système) ?

J'ai testé le code suivant :
Code:

1 2 3 4 5 6 7 int ii = 0; while(true) { QUdpSocket **socket = new QUdpSocket(); delete(socket); qDebug() << ++ii; }
et j'ai créer puis libéré plusieurs millions de socket sans que la mémoire sature. Donc à priori, pas de problème ici.
02/07/2010, 12h53
atmakefka

D'accord, merci!
Ce qui me gêne un peu c'est de me dire que valgrind ne me dira jamais qu'il n'y a aucun problème de mémoire si je fais mon application avec Qt. Mais bon, c'est peut être le cas aussi avec wxWidgets.
02/07/2010, 13h12
Gulish

Je dis ça au hasard, mais ne faut il pas créer une instance de QCoreApplication en début de main(), puis lancer le exec() ? Ca a peut être une incidence (je dis ça vraiment sans fondement). Petit extrait de la doc :

Citation:

The QCoreApplication class provides an event loop for console Qt applications.

This class is used by non-GUI applications to provide their event loop. For non-GUI application that uses Qt, there should be exactly one QCoreApplication object. For GUI applications, see QApplication.

QCoreApplication contains the main event loop, where all events from the operating system (e.g., timer and network events) and other sources are processed and dispatched. It also handles the application's initialization and finalization, as well as system-wide and application-wide settings.

The command line arguments which QCoreApplication's constructor should be called with are accessible using arguments(). The event loop is started with a call to exec(). Long running operations can call processEvents() to keep the application responsive.

Some Qt classes, such as QString, can be used without a QCoreApplication object. However, in general, we recommend that you create a QCoreApplication or a QApplication object in your main() function as early as possible. The application will enter the event loop when exec() is called. exit() will not return until the event loop exits, e.g., when quit() is called.

An application has an applicationDirPath() and an applicationFilePath(). Translation files can be added or removed using installTranslator() and removeTranslator(). Application strings can be translated using translate(). The QObject::tr() and QObject::trUtf8() functions are implemented in terms of translate().

The class provides a quit() slot and an aboutToQuit() signal.

Several static convenience functions are also provided. The QCoreApplication object is available from instance(). Events can be sent or posted using sendEvent(), postEvent(), and sendPostedEvents(). Pending events can be removed with removePostedEvents() or flushed with flush(). Library paths (see QLibrary) can be retrieved with libraryPaths() and manipulated by setLibraryPaths(), addLibraryPath(), and removeLibraryPath().

On Unix/Linux Qt is configured to use the system local settings by default. This can cause a conflict when using POSIX functions, for instance, when converting between data types such as floats and strings, since the notation may differ between locales. To get around this problem call the POSIX function setlocale(LC_NUMERIC,"C") right after initializing QApplication or QCoreApplication to reset the locale that is used for number formatting to "C"-locale.

See also QApplication, QAbstractEventDispatcher, QEventLoop, Semaphores Example, and Wait Conditions Example.

G.
02/07/2010, 13h15
atmakefka

Merci pour votre réponse.
Je ne peux pas tester avant ce soir, mais il semblerait que d'autres personnes aient rencontré ce problème alors qu'elles créent une application et la lance avec exec.

En fait je n'ai pas ça car je n'ai pas spécialement besoin d'une interface graphique, je suis plus intéressé par les modules de gestion du réseau ou des threads de Qt.
02/07/2010, 13h16
gbdivers

A priori, le problème sera le même, quelque soit la lib utilisée (wx, gtk...)
Mais tu peux quand même utiliser valgrind. Il faut juste regarder le détail de message pour trouver ceux qui correspondent au framework et ceux qui sont spécifique à ton application (et que tu peux donc corriger).

Je dirais a priori que Qt peut être utilisé sans problème pour des architectures client/serveur de taille raisonnable (mais jusqu'à combien de connections ? Aucune idée ! Je n'ai pas trouvé d'application Qt sur internet qui gèrent "beaucoup" de connections)
02/07/2010, 13h33
Gulish

Citation:

En fait je n'ai pas ça car je n'ai pas spécialement besoin d'une interface graphique, je suis plus intéressé par les modules de gestion du réseau ou des threads de Qt.

QCoreApplication elle gère l'event loop du système et une QApplication étend QCoreApplication pour en plus gérer l'interface graphique.

En gros, si tu fais une appli réseau, tu dois déclarer une QCoreApplication.

G.
02/07/2010, 13h47
atmakefka

D'accord, merci. Mais c'est bizarre car les sockets semblaient fonctionner sans que j'ai déclaré de QCoreApplication.
02/07/2010, 14h02
gbdivers

Tout va dépendre comment tu utilises tes sockets.

Avec une approche synchrone (connection bloquante), tu attends la fin de la fonction appelé et donc, tu n'as pas besoin de l'event loop (donc pas besoin de QApplication ou QCoreApplication)

Par contre, dans une approche asynchrone, tu en auras besoin.

Regarde les 2 exemples suivants, faisant la même chose mais avec les 2 approches :
- http://qt.developpez.com/doc/latest/...uneclient.html
- http://qt.developpez.com/doc/latest/...uneclient.html

Citation:

The asynchronous (non-blocking) approach. Operations are scheduled and performed when control returns to Qt's event loop. When the operation is finished, QTcpSocket emits a signal. For example, QTcpSocket::connectToHost() returns immediately, and when the connection has been established, QTcpSocket emits connected().

The synchronous (blocking) approach. In non-GUI and multithreaded applications, you can call the waitFor...() functions (e.g., QTcpSocket::waitForConnected()) to suspend the calling thread until the operation has completed, instead of connecting to signals.

Dans tous les cas, l'ajout de QCoreApplication ne résout pas ton problème initial de détection de fuites (j'ai testé ton code en ajoutant QCoreApplication, sans résultat)
02/07/2010, 14h36
atmakefka

Merci beaucoup !
03/07/2010, 23h35
LittleWhite

Bonjour

Récemment j'ai eu un problème de fausses fuite de mémoire, assez semblable à celui là, avec la Glib. Pour retiré la plupart des fausses erreurs il faut utiliser des variables d'environnement qui enlève les optimisations faites sur la mémoire.
Vous pourrez trouver plus de détail sur un post que j'avais ouvert, dans la section Glib.
04/07/2010, 09h22
yan

Y as t'il une fuite mémoire? je dirais que oui et non.
Oui car y as apparemment quelque chose qui n'est pas dés-alloué et non car elle n'est surement pas dangereuse et elle ne grandira pas.
Si ce simple fait te rend réfractaire alors dit toi que c'est pareil dans gtk, wxWidget, p_thread, le kernel linux,...

La fuite mémoire n'est pas forcement du à Qt lui même. Mais plutôt de ce qu'il exploite comme lib tierce. Au pire regarde le code pour voir à quoi cela correspond et si c'en est une de Qt tu peut faire un bug report.
Mais t'inquiète pas, il y en as très très peu dans le code de Qt lui même.