Discussion :

[dodobibi]

bonjour,

Souhaitant profiter de QxMemLeak sous OSX, j'ai tenté de compiler QxOrm avec l'option _QX_USE_MEM_LEAK_DETECTION.

Ca ne compilait pas...

Le problème semle venir de certaines variables locales définies dans

• QxMemLeak/fixed_mem_pool.h (ligne 175)
• QxMemLeak/static_mem_pool.h (ligne 190)

qui portent le nom "__block".
"__block" est un nom réservé sous OSX.

J'ai refactorisé "__block" en "__block_" et la compilation de QxOrm avec QxMemLeak se déroule sans problème.

Maintenant, quel que soit le projet (testé avec QxBlog et mon projet), le programme "abort()" dès le lancement (Ligne 424 debug_new.cpp)
Voici la pile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
0	__pthread_kill		0	0x7fff91dbace2	
1	pthread_kill		0	0x7fff925bc7d2	
2	abort		0	0x7fff925ada7a	
3	qx::memory::__debug_new_recorder::free_pointer	debug_new.cpp	424	0x100a995c0	
4	operator delete[]	mem_leak.h	53	0x10017e184	
5	QFSFileEngineIterator::advance		0	0x10129fd02	
6	QFSFileEngineIterator::next		0	0x101298343	
7	QDirIteratorPrivate::advance		0	0x10125ceef	
8	QDirIterator::next		0	0x10125d0ac	
9	QDir::entryList		0	0x10125a6fb	
10	QDir::entryList		0	0x10125a877	
11	QFactoryLoader::update		0	0x1012af21c	
12	QFactoryLoader::QFactoryLoader		0	0x1012b0c8c	
13	loader		0	0x101182940	
14	QSqlDatabasePrivate::init		0	0x101184536	
15	QSqlDatabase::addDatabase		0	0x101184aa4	
16	qx::QxSqlDatabase::createDatabase	QxSqlDatabase.cpp	58	0x100aedf57	
17	qx::QxSqlDatabase::getDatabaseByCurrThreadId	QxSqlDatabase.cpp	44	0x100aee593	
18	qx::QxSqlDatabase::getDatabase	QxSqlDatabase.h	120	0x1000716cc	
19	qx::dao::detail::IxDao_Helper::init	QxDao_Helper.inl	182	0x1000717fc	
20	qx::dao::detail::QxDao_Helper<author>::QxDao_Helper	QxDao_Helper.inl	226	0x1000fc0d1	
21	qx::dao::detail::QxDao_CreateTable<author>::createTable	QxDao_CreateTable.inl	37	0x1001ac03a	
22	qx::dao::create_table<author>	QxDao.h	855	0x1001ac6f4	
23	main	main.cpp	26	0x10016d681	
...	<plus>

les appels "operator delete" (ligne 52 mem_leak.h) passent sans problème, c'est les appels à
"operator delete[]" (ligne 53 mem_leak.h" qui lancent "abort()" via _DEBUG_NEW_ERROR_ACTION.

Si quequ'un a la solution ? Je suis preneur !

[QxOrm]

qui portent le nom "__block".
"__block" est un nom réservé sous OSX.

Merci je ferai cette modif pour que au moins ça compile correctement

Le module QxMemLeak me permet de vérifier qu'il n'y a pas de fuite mémoire dans la bibliothèque QxOrm, et je fais ces vérifications essentiellement sous Windows. J'avais également testé ce module sous Linux avec les 1ère versions de QxOrm et ça fonctionnait correctement.

Cependant, sous Linux, il y a des outils beaucoup plus complets, comme par exemple Valgring (je ne sais pas si ça existe sous OSX). Je conseille donc d'utiliser cet outil sous Linux plutôt que QxMemLeak.

Sous Windows, il n'y a rien et Qt ne fournit rien non plus pour détecter les fuites mémoire (ou alors je n'ai pas trouvé et je ne connais pas). C'est pourquoi j'ai utilisé la bibliothèque suivante (http://wyw.dcweb.cn/leakage.htm) qui me rappelle ce qu'on a avec les MFC et qui est très très pratique.

Est-ce que Valgrind (ou un équivalent) existe sous OSX ?
Si oui je te conseille d'utiliser ce type d'outil.
Si non...... ça va être compliqué pour t'aider (pour ma part en tout cas) car je ne reproduis pas ton problème sous Windows et Linux (je vais quand même refaire des tests avec la 1.1.9 pour être certain), et je n'ai pas de Mac pour tester. Peut-être qu'en essayant de deboguer de ton côté tu peux trouver la solution, mais je sais que c'est pas évident !

[dodobibi]

Est-ce que Valgrind (ou un équivalent) existe sous OSX ?

Oui, j'ai compilé valgrind sous OSX, mais c'est très lent pour tester mon prog avec valgrind, c'est pourquoi je voulais tester QxMemLeak.

je ne reproduis pas ton problème sous Windows

Sous Windows (msvc2010), je viens de tester QxBlog avec QxMemLeak activé et ça ne fonctionne pas non plus (tentative de désallocation d'un char* ...). Le problème est différent sous Windows et sous OSX. Je pense en effet que QxMemLeak gère mal les différences entre les différents compilateurs. Il faudrait que je teste sur linux (j'ai bien un poste sur Ubuntu, mais je n'ai pas installé l'environnement de dev dessus.)

J'abandonne donc QxMemLeak au profil de valgrind.

A partir du moment ou il n'y a pas de fuites de mémoires sous OSX (valgrind), il ne devrait pas y en avoir sous Windows...

Sous windows, il existe drmemory. Mais je n'ai pas réussi à le faire fonctionner avec des projets Qt.

PS : Le lien (http://wyw.dcweb.cn/leakage.htm) est mort ?!?

[QxOrm]

Je viens de tester avec QxOrm 1.1.9 :
- sous msvc2008, aucun problème pour détecter les fuites mémoire ;
- sous linux avec GCC 4.4.1, j'ai le même problème que toi ("abandon").

C'est donc une régression (en tout cas pour Linux) par rapport aux 1ère versions de QxOrm, j'essaierai d'apporter une correction...

PS : Le lien (http://wyw.dcweb.cn/leakage.htm) est mort ?!?

Je n'arrive pas à y accéder non plus pour le moment.
Peut-être que le lien est mort en effet.