~2000 ошибок в QApplication !!!

[SLiDER]

Сегодня возникла насущная необходимость половить баги с динамической памятью. Перестроил я проект (VS2003 & Qt3.3.4) с использованием утилиты DevPartner Studio v.7.2. И, о ужас!!!! Что я увидел!!! Приблизительно 2000 ошибок только при вызове конструктора Qapplication, плюс 4 утечки памяти при выгрузке qt*.dll.
Дальше больше. При изменении размера окна, увеличение количества ошибок приобрело лавинный эффект.
Умом понимаю, что что-то здесь не так, но не могу понять что. Может, кто сталкивался, объясните, пожалуйста, а то что-то не по себе как-то. Но глюкалово знатное!!!
З.Ы. Тоже самое творится и на простейшем примере из визарда.

[Sergeich]

А что вообще такое DevPartner Studio? И зачем он тебе?

[SLiDER]

DevPartner это набор утилит от фирмы Compuware (авторы SoftIce) которые весьма не плохо встраиваются VS (хотя могут работать и самостоятельно) и умеют делать следующее:
1. Автоматический отлов багов связаных с динамическим распределением памяти, как то различного рода утечки, выходы за пределы массивов и т.п. (пожалуй самое важное).
2. Подробнейший анализ производительности программы (типа intel vtune).
3. Анализ покрытия кода тестами (не разу толком этой штукой не пользовался).
4. Анализ работы распределенных приложений.
Сайт конторы находится здесь -> http://www.compuware.com
конкретная информация по продукту здесь -> http://www.compuware.com/products/devpartner/enterprise.htm

З.Ы. Частичный аналог данного софта есть у IBM/Rational, как называется сейчас не вспомню, но входит во все enterprise версии всяких RationalRose и RationalXDE.

[agrigoriev]

Что касается 2000 и больше ошибок при работе: кликни explain.
Там ты увидишь что все эти ошибки возникают в результате того, что блок динамической памяти выделяется malloc а освобождается delete.
Я думаю это штатная ситуация в qt.

Что касается утечек внутри qt - меня это тоже всегда интересовало
Если присмотреться есть ещё и утечки ресурсов.

Кстати софт этот часто показывает утечки во время исполнения когда не находит в пределах области видимости деструкции объекта. Например когда я делаю

QListViewItem* lvi=QListViewItem(mylistview);
тем самым делая владельцем элемента листвью. Т. е. когда деструкцией объекта занимается объект-владелец, он также показывает runtime memory leak. Такие ситуации ваще в qt сплош и рядом.

[SLiDER]

На счет

блок динамической памяти выделяется malloc а освобождается delete.

похоже это действительно так (если верить DevPartner-у)  :?
Но вот ведь незадача, после этакого обвала "ошибок" софтина (DevPartner) совсем дуреет и перестает реагировать на все остальное. Я специально, в простеньком тесте, насажал ошибок и он не одной не нашел, зараза !!! И это мне уже непонятно.
У энтой проги есть некий пункт который позволяет определить правила поиска ошибок (Error Detection Rules) и в нем фишка под названием Suppressions  где перечисляется набор правил при поиске ошибок связанных с какими либо DLL. Но вот как их создавать или редактировать непонятно, разрешают только добавлять уже готовые. Синтаксис похоже xml-евский, но вот, что конкретно нужно написать, чтобы он отстал от qt*.dll непонятно.

В таком выделении памяти (через malloc) ничего странного на мой взгляд нет. Уже давно известно что в С++ нет ничего тормознутее оператора new, особенно при создании большого числа малых объектов (почитайте хотя бы Александреску). Недаром же в STL сплош и рядом предлагают создавать свои распределители памяти. И ни кто это ошибкой не считает, а тут на тебе, такой номер. В общем, с этим надо как то боротся. Heeeeeeeeelp me !!!!!

З.Ы. Ну а на счет реальных утечек, то они, по моему, всетаки, имеются.  

[Denwer]

Что называется доверяй, но проверяй. Данной совтине верить то можно, если сам знаешь чему именно верить. Так вот у всего есть свои ограничения и пороки. У девпартнера ни без этого. Его механицм основан на подмене вызовов функций на свои функции, которые в свою очередь после некоторого анализа параметров просто вызывают нужные виндовские или CRTшные. А проблема то бывает в случае если его DLL выгрузиться раньше другой, в которой и происходит освобождение памяти, в данном случае он посчитает что память никто не освободил. Этот факт надо учитывать.
Дальше. По поводу выделения/освобождения памяти. На это счет есть стандарт С++. Память выделенная черз malloc должна освобождаться через free, и никак не иначе. И чем отличается new и malloc тоже нужно знать. Разница просто огромнейшая. Описывать не буду, по этому поводу написано много статей в инете.  Могу лишь дать совет, что бы не использовали тот метод без ооочень хорошего понимая данной проблемы. А в QT возможно это сделано потому что у них перегружены new и delete, утвержать не берусь не работаю с данной либой. И последнее, STL не рекомендует сплошь и рядом создавать свои распределители.
ЗЫ: И если в QT сделано так, то закройте на это глаза, потому как компетенция авторов очень высока, что бы можно было предположить о такой грубой ошибке.