Compatibilité de QxMemLeak avec OSX

Version imprimable

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...:aie:

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.:ccool:

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:

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 !:calim2:

10/10/2011, 10h17
QxOrm

:salut:

Citation:

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 !
10/10/2011, 13h05
dodobibi

:salut:

Citation:

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.

Citation:

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 ?!?
10/10/2011, 15h21
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...

Citation:

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.