Explosion de la consommation mémoire

Version imprimable

Bonjour,

J'ai un soucis avec QThread. Voilà le soucis:

Je suis en train d'écrire une système de log avec architecture : un LogManager qui contient les fonctions de log ( trace, warning , ... ) et une collection d'"engine" qui eux s'occupe d'écrire les logs proprement dit.

Les engines tourne dans un thread, chacun le leur et la communication entre le LogManager et les engines se fait via les signaux/slots.

Cependant j'ai un soucis, la mémoire vive utilisé par l'application explose et très rapidement ( avec une boucle infinie avec un trace("TEST") et 4 engines => 15 secondes = 1Go5 de mémoire prise ). J'ai donc pensé a une leak, sauf que il n'y a pas d'allocation dynamique dans le code.
Ci dessus des extraits de code:

La méthode pour ajouter un engine:
Code:

1 2 3 4 5 6 7 8 9 void LogManager::addLoggerEngine(QString engineName, LoggerEngine* engine) { m_loggerEngines.insert(engineName, engine); engine->moveToThread(thread); /* Work but cause a memory leak, had to fix that */ connect(this, SIGNAL(logMessage(LogManager::LogLevel, QList<QVariant>)), engine, SLOT(writeFormatted(LogManager::LogLevel, QList<QVariant>))); thread->start(); /* line that cause leak concern QDateTime::currentDate().ToString("format") */ emit loggerEngineAdded(engineName); }
La méthode pour loguer:
Code:

1 2 3 4 void LogManager::log ( LogLevel level, const QList<QVariant> & args ) { emit logMessage(level, args); }
Prototype du signal:

Code:

void logMessage(LogManager::LogLevel level, QList<QVariant> args);

Un des slots: ( tous on le même soucis )
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 void ConsoleLoggerEngine::writeFormatted(LogManager::LogLevel level, QList<QVariant> messages ) { if(!m_isEnabled) return; if (messages.isEmpty()) return; if(!isLogLevelEnabled(level)) return; QString header = '[' + QTime::currentTime().toString("hh:mm:ss.zzz") + "] [" + LogManager::logLevelToString(level) + "] "; QString padding; *stdstream << header; padding.append(' '); int count = 0; Q_FOREACH(const QVariant& out, messages) { if (!out.isNull()) { if (count != 0) *stdstream << padding; *stdstream << out.toString(); } count++; } *stdstream << endl; }
En sachant que si je commente ce code = plus de soucis

Cordialement Mathieu

04/07/2012, 19h59
yan

Salut.
C'est quoi stdstream ?

Bonjour
stdstream est un QTextStream binder sur la sortie console.

Code:

1
2
3
4
5
6
7
8
9
ConsoleLoggerEngine::ConsoleLoggerEngine(QObject *parent) : LoggerEngine(parent)
{	
	stdstream = new QTextStream(stdout);
}
 
ConsoleLoggerEngine::~ConsoleLoggerEngine()
{
	delete stdstream;
}

05/07/2012, 09h47
yan

Comment voie tu la mémoire utilisé?
Es ce que ton appli crash a cause d'un manque de mémoire?
05/07/2012, 10h29
lange59

J'utilise le gestionnaire de tache. Je sais bien que ce n'est pas forcément très précis mais je vois la mémoire vive monté très rapidement donc pas on signe ^^.

Si j'attend , l'application ne plante pas , elle ralenti mais je suis cappé en RAM utilisé ( 8Go dont 6Go5 par l'application si j'en crois le gestionnaire des taches )
05/07/2012, 10h34
yan

Citation:

Envoyé par lange59

J'utilise le gestionnaire de tache. Je sais bien que ce n'est pas forcément très précis mais je vois la mémoire vive monté très rapidement donc pas on signe ^^.

^^

Bizarre. Car dans le code que tu donne, il n'y as rien de spéciale.
Tu es sur que c'est lié à ton slot?
N'aurais tu pas une sorte à ton slot de manière récursive?
Que contient QList<QVariant>?
05/07/2012, 10h39
lange59

QList<QVariant> contient des QVariant qui correspondande au message a log, dans le cas présent une QString = "TEST" mais ca peut être n'importe quoi.

C'est forcement lié au slot étant donné que si je le commente, donc il est appelé mais sans rien faire = plus de problèmes.
De même si je supprime le Qtime::currentTime().toString(""), plus de soucis.
Si encore je pouvais m'en passer mais bon j'ai besoin de la date ^^.

J'ai pas pensé a une appel récursif, je vais regarder mais le code est vraiment triviale , ya rien de complexe dedans.
Un soucis de polymorphisme peut etre ?

Désolé pour le double post, voici un code qui permet de reproduire l'erreur :

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
 
 
#include <QObject>
 
class Receiver : public QObject
{
	Q_OBJECT
public:
	Receiver() {}
	~Receiver() {}
 
public slots:
	void Test()
	{
		QString header = "["+QTime::currentTime().toString("hh:mm:ss zzz")+"]";
		qDebug() << header;
	}
};
 
class Emitter : public QObject
{
	Q_OBJECT
public:
	Emitter() {}
	~Emitter() {}
 
	void Test()
	{
		emit SignalTest();
	}
 
signals:
	void SignalTest();
 
};
 
#include "main.moc"
 
int main(int argc, char *argv[])
{
	QCoreApplication a(argc, argv);
 
	Emitter emitter;
 
	QThread *thread = new QThread(&emitter);
 
	for(auto i = 0; i < 5; i++)
	{
		Receiver *r = new Receiver();
          QThread *thread = new QThread(&emitter);
		r->moveToThread(thread);
		QObject::connect(&emitter, SIGNAL(SignalTest()), r,  SLOT(Test()));
		thread->start();
	}
 
	forever
	{
		emit emitter.Test();
	}
 
 
	return a.exec();
}

Si on exécute ça on remarque bien que la mémoire utilisé par l'application augmente de façon très rapide sans qu'il y est de raison.

05/07/2012, 21h02
yan

Salut.
Il manque l'execution de l'eventloop principale : a.exec().

C'est peut être dû à cela.

Je n'ai pas d'installe de Qt sous la main pour tester :/
05/07/2012, 21h22
bobti89

Il me semble que les timers doivent être exécutés dans le thread principal, le problème vient peut-être de la.

Regarde ce topic, il peut t'intéresser.
06/07/2012, 09h14
lange59

Bonjour,

Timer ? Ya pas de timers dans le code.

Même en ajoutant la boucle principale, cela ne change rien, la mémoire augmente toujours. De toute façon étant donnée que j'utilise un forever, le a.exec() ne sera jamais atteint.
Mais la doc de Qt précise que un QThread , lance par défaut une boucle d'évement dans le run() et les slots sont correctement appelés dans les Receiver donc c'est que les signaux/slots marche sans soucis.

C'est assez incompréhensible comme problème :p
06/07/2012, 09h27
yan

Citation:

Envoyé par lange59

Même en ajoutant la boucle principale, cela ne change rien, la mémoire augmente toujours. De toute façon étant donnée que j'utilise un forever, le a.exec() ne sera jamais atteint.

Qt délègue parfois la destruction de mémoire à l'event loop pour ne par retarder un traitement. Si tu ne l'appel pas, tu bloque une partie de QT. D'ou je pense ton problème.

Pourquoi un forever? Tu peux aussi executer l'eventloop dans ton forever avec
http://qt-project.org/doc/qt-4.8/qco...#processEvents

Après modification:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
	QCoreApplication a(argc, argv);
 
	Emitter emitter;
 
	QThread *thread = new QThread(&emitter);
 
	for(auto i = 0; i < 5; i++)
	{
		Receiver *r = new Receiver();
          QThread *thread = new QThread(&emitter);
		r->moveToThread(thread);
		QObject::connect(&emitter, SIGNAL(SignalTest()), r,  SLOT(Test()));
		thread->start();
	}
 
	forever
	{
		emitter.Test();
		QCoreApplication::processEvents();
	}
 
 
	return a.exec();

Résultat: Aucun changement, la mémoire utilisé monte toujours.
Je vais finir par croire qu'il y a un soucis du coté des threads avec Qt ...

06/07/2012, 09h52
yan

tu utilise quelle versionde Qt? tu es sous windows?
06/07/2012, 14h02
lange59

Qt Version 4.8.2, compilé avec MSVC2010 en 64 Bits Shared.
Le bug se produit aussi en version 32Bits.
15/07/2012, 04h07
lange59

Up.

Le problème est toujours là. Je commence a croire qu'il y a un soucis de libération de ressources avec le système de Signals/Slots quand on l'utilise pour la connection inter-thread.
J'ai continué à faire des tests et le problème se repete sans cesse.

Si quelqu'un a une réponse je suis preneur :)

Cordialement lange
15/07/2012, 13h14
yan

as tu essayé d'avoir a.exec ?

Purée ca me rend fou.

C'était bien ça. J'ai modifier le code et utliser des QTimer pour envoyer les signaux à mes threads et ajouter un a.exec() comme retour du main et là plus de soucis.
C'est quand même étrange , on dirait que Qt garde en stocks les paramétres de slots et ne les "nettoie" que si une boucle d'evenement est lancé dans le thread principal.
Le problème c'est que ca n'est indiqué nul part dans la doc de Qt (et je l'ai fouillé de fond en comble ).

Merci pour le coup de main. Je vais enfin avoir mon système de logs multithreaded :).

EDIT: C'est pas ça le problème, j'ai trouvé d'ou ca vient :).

Je viens a l'instant de m'en rendre compte, si je diminue au mininium la vitesse de tick du QTimer (donc timer.start(): la mémoire utilisé augmente comme pendant le "bug", quand je l'a met a un "niveau raisonnable" ( timer.start(1) ) = plus de soucis.
C'est donc pas un bug, c est le système d'evenement de Qt qui n'arrive pas gérer aussi vite les evenements donc il les met en queue, d'ou une copie des parametres d'ou une augmentation de la mémoire :).

Exemple de Code:

La classe Thread est juste une sous classe de QThread qui sert de relais pour les signaux entre le thread principal et une sous classe QObject vivant dans le thread et qui ne fait rien de spécial ( log l'id du thread courant )

Code qui "leak":
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Thread thread1; Thread thread2; Thread thread3; Thread thread4; thread1.start(); thread2.start(); thread3.start(); thread4.start(); forever { thread1.TestFonction(); thread2.TestFonction(); thread3.TestFonction(); thread4.TestFonction(); } return a.exec(); // return 0; Les deux leak
Cette version "leak" aussi:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Thread thread1; Thread thread2; Thread thread3; Thread thread4; thread1.start(); thread2.start(); thread3.start(); thread4.start(); QTimer timer1; QObject::connect(&timer1, SIGNAL(timeout()), &thread1, SLOT(TestFonction())); QObject::connect(&timer1, SIGNAL(timeout()), &thread2, SLOT(TestFonction())); QObject::connect(&timer1, SIGNAL(timeout()), &thread3, SLOT(TestFonction())); QObject::connect(&timer1, SIGNAL(timeout()), &thread4, SLOT(TestFonction())); timer1.start(); return a.exec();
Ces deux versions ne leak pas:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Thread thread1; Thread thread2; Thread thread3; Thread thread4; thread1.start(); thread2.start(); thread3.start(); thread4.start(); QTimer timer1; QObject::connect(&timer1, SIGNAL(timeout()), &thread1, SLOT(TestFonction())); QObject::connect(&timer1, SIGNAL(timeout()), &thread2, SLOT(TestFonction())); QObject::connect(&timer1, SIGNAL(timeout()), &thread3, SLOT(TestFonction())); QObject::connect(&timer1, SIGNAL(timeout()), &thread4, SLOT(TestFonction())); timer1.start(1); return a.exec();
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Thread thread1; Thread thread2; Thread thread3; Thread thread4; thread1.start(); thread2.start(); thread3.start(); thread4.start(); forever { thread1.TestFonction(); thread2.TestFonction(); thread3.TestFonction(); thread4.TestFonction(); Sleep(1); } return a.exec();
Cordialement Mathieu

15/07/2012, 20h00
yan

lors d'une connection entre thread, un évènement est ajouté à l'eventloop du thread pour executer le slot. Donc si tu en envoie trop tu fais exploser l'eventloop ^^