Нужен совет по отладке

[Ced]

Подскажите, а конструкция try - catch обязательно сработает при падении потока, если в catch (std::exeption &x)?
Уточню.

Код:

QDataStream &operator << (QDataStream &out, const MyData &data)
{
    out << data.state;
    QString  temp (data.value->typeName());
    if (temp =="float")
    {
        try
        {
            out << 0 << data.value->toFloat();
        }
        catch (std::exception &test)
        {
            qDebug () << data.value->toFloat() << ' ' << test.what () << '\n';
        }
    }
......

Такое обязательно должно сработать в случае ошибки?

[Пантер]

Такое вообще не сработает - Кьют не кидает исключения.

[Old]

Может кто посоветует средство анализа работы с памятью под винду?

VirtualBox + linux + valgrind

[Пантер]

От интелла была какая-то штука для поиска утечек памяти. Но, да, валгринд лучшее решение.
Я вообще не понимаю, как можно разрабатывать под виндой.

[Igors]

Может кто посоветует средство анализа работы с памятью под винду?

Тут (как выяснилось) много фанов неубогого Вындоуз, мол, если этот ОС самый популярный - то он же и лучший. Но всякий раз когда нужен инструмент типа valgrind (ну о наших Instruments я даже не говорю) - начинаются отмазки, выясняется что оно платное и вообще хз. Так что "увы"

Ну и, как Вы сами понимаете, такие прогоны конечно полезны - но они не панацея и всех ошибок не найдут. Локализуйтесь, покажите несколько мест падения в отладчике, может и придет какая мысля

[Ced]

Может кто посоветует средство анализа работы с памятью под винду?

VirtualBox + linux + valgrind

С этим есть технические проблемы. Отлаживаться придется под виндой.

[Ced]

Может кто посоветует средство анализа работы с памятью под винду?

Тут (как выяснилось) много фанов неубогого Вындоуз, мол, если этот ОС самый популярный - то он же и лучший. Но всякий раз когда нужен инструмент типа valgrind (ну о наших Instruments я даже не говорю) - начинаются отмазки, выясняется что оно платное и вообще хз. Так что "увы"

Ну и, как Вы сами понимаете, такие прогоны конечно полезны - но они не панацея и всех ошибок не найдут. Локализуйтесь, покажите несколько мест падения в отладчике, может и придет какая мысля

Я не фанат масдая. Просто ситуация вынуждает. Дома стоит Debian, но в силу обстоятельств отлаживать дома не могу.

[kambala]

поищи все места с ручным удалением указателя, может к одному из них потом идет обращение

[Ced]

ну кажется наконец зацепился.

   Локальные переменные      
      arrBlock   "\000\000\002´ïÊ\000\000\000\n\000P\000R\000O\000G\0007\000\000\000\014\004!\0045\004@\0042\0045\004@\000\000\000\001\000\000\000\030\000\000\000\235\000\000\000\002\000\000\000\002?ð\000\000\000\000\000\000\000\000\000\004\000M\000H\000\000\000\022\004\035\0040\004@\0040\0041\004>\004B\004:\0040ÿÿÿÿ\000\000"... (24438)   QByteArray
      out   @0x28cf98   QDataStream
         byteorder   QDataStream::BigEndian (0)   QDataStream::ByteOrder
         d   (null)   QScopedPointer<QDataStreamPrivate>

Я так понимаю, d   (null) - не нормально.
Теперь вопрос - каким образом я могу проверять состояние этого адреса?

[Пантер]

ну кажется наконец зацепился.

   Локальные переменные      
      arrBlock   "\000\000\002´ïÊ\000\000\000\n\000P\000R\000O\000G\0007\000\000\000\014\004!\0045\004@\0042\0045\004@\000\000\000\001\000\000\000\030\000\000\000\235\000\000\000\002\000\000\000\002?ð\000\000\000\000\000\000\000\000\000\004\000M\000H\000\000\000\022\004\035\0040\004@\0040\0041\004>\004B\004:\0040ÿÿÿÿ\000\000"... (24438)   QByteArray
      out   @0x28cf98   QDataStream
         byteorder   QDataStream::BigEndian (0)   QDataStream::ByteOrder
         d   (null)   QScopedPointer<QDataStreamPrivate>

Я так понимаю, d   (null) - не нормально.
Теперь вопрос - каким образом я могу проверять состояние этого адреса?

У тебя один или несколько потоков?

[Igors]

Я так понимаю, d   (null) - не нормально.

Чего это? Сам QByteArray у Вас хороший, распечатался, он вполне может иметь член QScopedPointer<QDataStreamPrivate> который сейчас null

Что конкретно имеете на вылете? Какое вообще IDE? Что оно показывает в окнах отладки?

[Ced]

Потоков несколько, но одновременно работает только один из них. Пересечения исключены. За это время нашел и устранил одну утечку памяти и некорректную работу с QVariant. В результате программа продвинулась на 1300 циклов и все равно падает. Массив заполняется в цикле параметрами типа QVariant. Установил, что падение всегда на одном и том же параметре. Сейчас пытаюсь подобраться к этому месту дебагером.

[Ced]

Какое вообще IDE? Что оно показывает в окнах отладки?

Сейчас дойду до новой точки ошибки (каждый цикл занимает примерно 20 минут) и отпишу подробнее.

[Ced]

Нарыл на форуме вот такое

Igors
А как насчет поюзать CrtDbg под виндой? утечки памяти обнаружает - а что нам еще нужно для полного счастья.
*
Давайте распишу ибо сам долго искал аналог valgrind' а под винду, пока не наткнулся на одном из форумов.

Кратко суть такая - перекрываем new/delete  - я сделал h-файл следующего вида win32_debug.h":

Код:

#ifndef WIN32_DEBUG_H
#define WIN32_DEBUG_H

#if(defined WIN32 && defined _DEBUG)
	#define WIN32_DEBUG
	#include <crtdbg.h>
	#define _CRTDBG_MAP_ALLOC // enable generation of debug heap alloc map
	#define new new( _NORMAL_BLOCK, __FILE__, __LINE__) // redefine "new" to get file names in output
#endif
 
#endif

далее включаем этот h-файл там где хотим поискать утечки.

в main делаем такой финт:

Код:

...
#ifndef WIN32_DEBUG_H
	#include "win32_debug.h"
#endif


int main(int argc, char *argv[])
{
	QApplication a(argc, argv);

#ifdef WIN32_DEBUG
	_CrtMemState _ms; 
	HANDLE hLogFile;
	hLogFile = CreateFile("../Debug/log/log_mem_leak.txt", GENERIC_WRITE, 
      FILE_SHARE_WRITE, NULL, CREATE_ALWAYS, 
      FILE_ATTRIBUTE_NORMAL, NULL);
   _CrtSetReportMode(_CRT_WARN, _CRTDBG_MODE_FILE);
   _CrtSetReportFile(_CRT_WARN, hLogFile);
	_CrtMemCheckpoint(&_ms); // now forget about objects created before
#endif
...
// тело программы
...
#ifdef WIN32_DEBUG
	_CrtMemDumpAllObjectsSince(&_ms); // dump leaks
	CloseHandle(hLogFile);
#endif		
	return res;
}

осталось включить этот win32_debug.h  в те файлы, где мы хотим поискать утечки памяти.
по завершении программы имеем лог-файл куда свалено все по обнаруженным утечкам памяти. Так new мы перекрыли, то все наши утечки ищем по имени файла . Например был файл my_file.cpp (и в него я сделал включение  win32_debug.h !) - ищем вхождение "my_file.cpp" и если утечки в нем были - находим строку примерно следующего вида:

Код:

Dumping objects ->
...
.\my_file.cpp(1691) : {37521} normal block at 0x015293A0, 4 bytes long.
 Data: <@   > 40 00 9F 03 

Видим что имеем утечку в файле my_file.cpp в строке 1691 - лезем в свой код и устраняем ошибку.
Не знаю как насчет кутэшных, но таким образом можно вычистить все свои косяки по работе с памятью.

Попробовал. У меня не работает. Файл лога не создается. Кто-то может прокомментировать?

[ViTech]

Попробуйте лучше что-нибудь готовое, типа Dr. Memory, Visual Leak Detector и т.п.