Russian Qt Forum

Qt => Вопросы новичков => Тема начата: Ced от Май 31, 2017, 15:22



Название: Нужен совет по отладке
Отправлено: Ced от Май 31, 2017, 15:22
Код:
void MyServer::sendToClient(/*QTcpSocket*/ QIODevice *pSocket, Message *toSend)
{
    QByteArray arrBlock;
    QDataStream out (&arrBlock, QIODevice::WriteOnly);

    out.setVersion (QDataStream::Qt_4_8);
    out << quint16 (0) << QTime::currentTime () << *toSend;
    out.device ()->seek (0);
    quint16  temp = arrBlock.size ();
    out << quint16 (arrBlock.size ()- sizeof (quint16));

    pSocket->write (arrBlock);
    pSocket->waitForBytesWritten (100);
}

Операция нормально выполняется 16810 раз и падает на pSocket->write (arrBlock);
Размеры arrBlock в подавляющем большинстве операций одинаковые и равны примерно 20КБайт.
У меня уже вывих мозга. Может кто посоветует, где искать?


Название: Re: Нужен совет по отладке
Отправлено: Пантер от Май 31, 2017, 15:25
Я советую смотреть в других местах. Погоняй под валгриндом.


Название: Re: Нужен совет по отладке
Отправлено: Ced от Май 31, 2017, 15:26
Я советую смотреть в других местах. Погоняй под валгриндом.

А что такое валгринд?


Название: Re: Нужен совет по отладке
Отправлено: Пантер от Май 31, 2017, 15:41
http://valgrind.org/

Но это под Линукс.
Ты портишь памыть где-то в другом месте. Или передаешь в метод что-то невалидное. Очень смущает работа через указатели. Это тебе не СИ, тут указатели нужны как можно реже.


Название: Re: Нужен совет по отладке
Отправлено: Ced от Май 31, 2017, 15:53
http://valgrind.org/

Но это под Линукс.

А под виндой что-то подобное?


Название: Re: Нужен совет по отладке
Отправлено: Igors от Май 31, 2017, 16:00
Операция нормально выполняется 16810 раз и падает на pSocket->write (arrBlock);
Нужно постараться извлечь как можно больше из "места падения", что видно в отладчике, а не так себе просто "падает" и все. Возможно писать arrBlock сначала в файл чтобы потом его спокойно проверить. В общем найти "кто испорчен", потом уже как/когда


Название: Re: Нужен совет по отладке
Отправлено: Ced от Май 31, 2017, 16:10
Операция нормально выполняется 16810 раз и падает на pSocket->write (arrBlock);
Нужно постараться извлечь как можно больше из "места падения", что видно в отладчике, а не так себе просто "падает" и все. Возможно писать arrBlock сначала в файл чтобы потом его спокойно проверить. В общем найти "кто испорчен", потом уже как/когда

Перед записью я его сам формирую. Имею возможность посмотреть все формирование. Правда делал это уже много раз. Пока криминала на вижу. И не совсем понимаю, а как содержание arrBlock может валить write? Иначе говоря, а что там искать?
Дополнительно. Размер массива больше, чем я написал в начале. Он составляет 34221 байт.


Название: Re: Нужен совет по отладке
Отправлено: Пантер от Май 31, 2017, 16:13
Ошибка может быть совершенно в другом месте.


Название: Re: Нужен совет по отладке
Отправлено: Ced от Май 31, 2017, 16:16
Ошибка может быть совершенно в другом месте.

Это я понял. Не понял, как это место искать под виндой?


Название: Re: Нужен совет по отладке
Отправлено: Old от Май 31, 2017, 16:16
Операция нормально выполняется 16810 раз и падает на pSocket->write (arrBlock);
Куда указывает указатель pSocket в момент падения?


Название: Re: Нужен совет по отладке
Отправлено: Ced от Май 31, 2017, 16:18
Операция нормально выполняется 16810 раз и падает на pSocket->write (arrBlock);
Куда указывает указатель pSocket в момент падения?

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


Название: Re: Нужен совет по отладке
Отправлено: Ced от Май 31, 2017, 16:23
Операция нормально выполняется 16810 раз и падает на pSocket->write (arrBlock);
Куда указывает указатель pSocket в момент падения?

Вышел на место падения пока адрес сокета такой
Цитировать
   
            clientSocket   @0x7fe3b618   QTcpSocket
               [QAbstractSocket]   @0x15f97928   QAbstractSocket
                  [QIODevice]   @0x15f97928   QIODevice
                  staticMetaObject   @0x67fb3104   QMetaObject
               staticMetaObject   @0x67fee15c   QMetaObject
Сейчас пройду до падения


Название: Re: Нужен совет по отладке
Отправлено: Igors от Июнь 01, 2017, 07:43
И не совсем понимаю, а как содержание arrBlock может валить write? Иначе говоря, а что там искать?
Начинать нужно с самого внимательного обзора места падения в отладчике. На какой машинной команде вылет? Какой строке кода она соответствует в отладчике? Посмотреть this и др указатели/ссылки, может они калечные. Повторюсь - найти "кто испорчен", дальше ставить условный breakpoint и ловить (да, как правило ошибки далеко от этого места)


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 01, 2017, 08:14
И не совсем понимаю, а как содержание arrBlock может валить write? Иначе говоря, а что там искать?
Начинать нужно с самого внимательного обзора места падения в отладчике. На какой машинной команде вылет? Какой строке кода она соответствует в отладчике? Посмотреть this и др указатели/ссылки, может они калечные. Повторюсь - найти "кто испорчен", дальше ставить условный breakpoint и ловить (да, как правило ошибки далеко от этого места)

Пытаюсь идти по такому пути. Проблема в том, что под отладчиком и без оного программа падает на разных циклах обработки. Еще точка падения зависит от детальности отладки, на какую глубину заходил. Из за этого никак не могу точно локализоваться.


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 01, 2017, 08:28
Такое поведение наводит на мысль о нарушении границ отведенных областей памяти. И, как тут уже говорено, не в точке падения. И даже не факт, что в том цикле, где происходит падение. Может кто посоветует средство анализа работы с памятью под винду?


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 01, 2017, 10:38
Подскажите, а конструкция 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';
        }
    }
......

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


Название: Re: Нужен совет по отладке
Отправлено: Пантер от Июнь 01, 2017, 10:45
Такое вообще не сработает - Кьют не кидает исключения.


Название: Re: Нужен совет по отладке
Отправлено: Old от Июнь 01, 2017, 10:51
Может кто посоветует средство анализа работы с памятью под винду?
VirtualBox + linux + valgrind


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


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

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


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 01, 2017, 11:21
Может кто посоветует средство анализа работы с памятью под винду?
VirtualBox + linux + valgrind

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


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

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

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


Название: Re: Нужен совет по отладке
Отправлено: kambala от Июнь 01, 2017, 12:04
поищи все места с ручным удалением указателя, может к одному из них потом идет обращение


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 01, 2017, 12:44
ну кажется наконец зацепился.
Цитировать
   Локальные переменные      
      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) - не нормально.
Теперь вопрос - каким образом я могу проверять состояние этого адреса?


Название: Re: Нужен совет по отладке
Отправлено: Пантер от Июнь 01, 2017, 14:03
ну кажется наконец зацепился.
Цитировать
   Локальные переменные      
      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) - не нормально.
Теперь вопрос - каким образом я могу проверять состояние этого адреса?

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


Название: Re: Нужен совет по отладке
Отправлено: Igors от Июнь 01, 2017, 14:28
Я так понимаю, d   (null) - не нормально.
Чего это? Сам QByteArray у Вас хороший, распечатался, он вполне может иметь член QScopedPointer<QDataStreamPrivate> который сейчас null

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


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 01, 2017, 15:58
Потоков несколько, но одновременно работает только один из них. Пересечения исключены. За это время нашел и устранил одну утечку памяти и некорректную работу с QVariant. В результате программа продвинулась на 1300 циклов и все равно падает. Массив заполняется в цикле параметрами типа QVariant. Установил, что падение всегда на одном и том же параметре. Сейчас пытаюсь подобраться к этому месту дебагером.


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 01, 2017, 16:07
Какое вообще IDE? Что оно показывает в окнах отладки?

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


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 02, 2017, 17:22
Нарыл на форуме вот такое

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 - лезем в свой код и устраняем ошибку.
Не знаю как насчет кутэшных, но таким образом можно вычистить все свои косяки по работе с памятью.


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


Название: Re: Нужен совет по отладке
Отправлено: ViTech от Июнь 02, 2017, 17:52
Попробуйте лучше что-нибудь готовое, типа Dr. Memory (http://www.drmemory.org/), Visual Leak Detector (https://vld.codeplex.com/) и т.п.


Название: Re: Нужен совет по отладке
Отправлено: Igors от Июнь 03, 2017, 08:31
Ну вообще-то "утечки" и "вылет" взаимосвязаны лишь иногда. Находить утечки в любом случае полезно, но это не гарантирует устранение вылета.

А вот вставить проверки кучи (есть ли битые блоки) очень даже к месту. В MSVC что-то есть. но помню смутно, только что ужасно корявое :) Хотя и это ничего не гарантирует (куча сможет быть Ok), но все же это конкретный шаг который можно сделать за день-два

Лучший способ - получить больше информации об ошибке (я все время повторяюсь  :))


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 03, 2017, 09:00
Ну вообще-то "утечки" и "вылет" взаимосвязаны лишь иногда. Находить утечки в любом случае полезно, но это не гарантирует устранение вылета.

А вот вставить проверки кучи (есть ли битые блоки) очень даже к месту. В MSVC что-то есть. но помню смутно, только что ужасно корявое :) Хотя и это ничего не гарантирует (куча сможет быть Ok), но все же это конкретный шаг который можно сделать за день-два

Лучший способ - получить больше информации об ошибке (я все время повторяюсь  :))

1. На счет взаимосвязи утечек и ошибки конечно же согласен, но в данном случае она есть. Каждый раз, находя утечку, я продвигаюсь. Программа работает дольше. Кроме того, без отладчика программа работает существенно дольше, чем под отладчиком. Очевидно. это связано с тем. что отладчик отъедает часть памяти.
2. К сожалению не знаю, как сделать проверку битого блока. Если посоветуете. буду весьма признателен.
3. Я так и не смог выйти в отладчике точно к месту падения. Оно меняется в зависимости от степени подробности отладки.


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 03, 2017, 09:02
Попробуйте лучше что-нибудь готовое, типа Dr. Memory (http://www.drmemory.org/), Visual Leak Detector (https://vld.codeplex.com/) и т.п.

С удовольствием. Вы первый, кто дал конкретные ссылки. С этого и начну.


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 03, 2017, 09:12
Попробуйте лучше что-нибудь готовое, типа Dr. Memory (http://www.drmemory.org/), Visual Leak Detector (https://vld.codeplex.com/) и т.п.

Одна проблема. По Вашим ссылкам лежат 64-разрядные приложения. Мне нужны 32-разрядные. Может посоветуете?


Название: Re: Нужен совет по отладке
Отправлено: kuzulis от Июнь 03, 2017, 09:49
Просто не нужно плодить потоки и внимательно и аккуратно все делать... И тогда не будет никаких утечек и прочих нехороших вещей.

PS: Возьмите уже Linux и прогоните с Valgrind. 


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 03, 2017, 10:03
Просто не нужно плодить потоки и внимательно и аккуратно все делать... И тогда не будет никаких утечек и прочих нехороших вещей.

PS: Возьмите уже Linux и прогоните с Valgrind. 

Потоками не страдаю. А про аккуратность знают все. От чего-то у всех периодически это не выходит:)


Название: Re: Нужен совет по отладке
Отправлено: Пантер от Июнь 03, 2017, 10:19
Еще совет - замени указатели на "умные" указатели (std::unique_ptr, std::shared_ptr)


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 03, 2017, 12:52
Еще совет - замени указатели на "умные" указатели (std::unique_ptr, std::shared_ptr)

Допустим. И каков ожидаемый результат?


Название: Re: Нужен совет по отладке
Отправлено: Пантер от Июнь 03, 2017, 13:11
1. Уменьшает утечки памяти.
2. Не дает работать с указателями вникуда.


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 03, 2017, 13:22
1. Уменьшает утечки памяти.
2. Не дает работать с указателями вникуда.

а в чем разница между двумя вариантами?


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 05, 2017, 14:24
Подскажите пожалуйста, какова максимальная длина QByteArray для 32-битной операционки?


Название: Re: Нужен совет по отладке
Отправлено: kambala от Июнь 05, 2017, 14:51
1. Уменьшает утечки памяти.
2. Не дает работать с указателями вникуда.

а в чем разница между двумя вариантами?
1 — просто утечка, 2 — потенциальный краш
Подскажите пожалуйста, какова максимальная длина QByteArray для 32-битной операционки?
INT_MAX, скорее всего 32767


Название: Re: Нужен совет по отладке
Отправлено: Old от Июнь 05, 2017, 15:41
Подскажите пожалуйста, какова максимальная длина QByteArray для 32-битной операционки?
Под вендой упретесь в 2Гб.


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 05, 2017, 19:52
А такая операция допустима?

Код:
List<x *>  a;
List<x *>  b;
......

a = b

если a перед присвоением был пуст, b - не пуст.


Название: Re: Нужен совет по отладке
Отправлено: Old от Июнь 05, 2017, 20:47
Операция то допустима, вы получите второй список с указателями на те-же самые объекты x.
Вы потом как эти объекты освобождаете? Повторных освобождений не делаете?


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 05, 2017, 20:53
Операция то допустима, вы получите второй список с указателями на те-же самые объекты x.
Вы потом как эти объекты освобождаете? Повторных освобождений не делаете?

Надеюсь, что нет. Сейчас все перепроверяю пошагово.


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 05, 2017, 20:56
Да. и мне удалось таки выйти на место падения.
Код:
void MyServer::sendToClient(/*QTcpSocket*/ QIODevice *pSocket, Message *toSend)
{
    QByteArray arrBlock;
    QDataStream out (&arrBlock, QIODevice::WriteOnly);

    out.setVersion (QDataStream::Qt_4_8);
    out << quint16 (0) << QTime::currentTime () << *toSend;
    out.device ()->seek (0);
    out << quint16 (arrBlock.size ()- sizeof (quint16));

    pSocket->write (arrBlock);
    pSocket->waitForBytesWritten (100);
    QThread::msleep (50);
}

Слот отрабатывает. Перед его завершением дебагер возвращается сперва ко второй строке, а за тем к первой. В этот момент и происходит падение. И вот еще что, если в дебагере идти медленно, падения скорее всего не произойдет. Последнюю задержку я вставил именно по этой причине.


Название: Re: Нужен совет по отладке
Отправлено: Old от Июнь 05, 2017, 21:06
Эта задержка ничего не дает.
Попробуйте изменить слот следующим образом:
Код
C++ (Qt)
void MyServer::sendToClient(/*QTcpSocket*/ QIODevice *pSocket, Message *toSend)
{
   QByteArray arrBlock;
   {
   QDataStream out (&arrBlock, QIODevice::WriteOnly);
 
   out.setVersion (QDataStream::Qt_4_8);
   out << quint16 (0) << QTime::currentTime () << *toSend;
   out.device ()->seek (0);
   out << quint16 (arrBlock.size ()- sizeof (quint16));
   }
 
   qDebug() << arrBlock.size();
   pSocket->write (arrBlock);
   pSocket->waitForBytesWritten (100);
}

Фигурные скобки нужны. Плюс понаблюдайте за размерами пакета.


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 05, 2017, 21:21
Размеры пакета 30221. Скобки сейчас поставлю.


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 08, 2017, 21:24
Ну вот, даю отчет о результатах.
1. Утечки нашел с использованием диспетчера задач. Последовательно двигался в дебагере и после каждого шага смотрел в диспетчер. Вполне рабочий инструмент.
2. Главная утечка оказалась на самом видном месте. QByteArrea arrBlock в приведенном мною тексте. В конце слота его надо было чистить.
Ну вот собственно и все. Две недели битвы увенчались успехом. Все, кто помогал, - спасибо.


Название: Re: Нужен совет по отладке
Отправлено: kambala от Июнь 08, 2017, 23:40
2. как-то странно, ведь в конце слота будет вызван деструктор arrBlock, который и так его очистит...


Название: Re: Нужен совет по отладке
Отправлено: Пантер от Июнь 09, 2017, 08:34
Ну вот, даю отчет о результатах.
1. Утечки нашел с использованием диспетчера задач. Последовательно двигался в дебагере и после каждого шага смотрел в диспетчер. Вполне рабочий инструмент.
2. Главная утечка оказалась на самом видном месте. QByteArrea arrBlock в приведенном мною тексте. В конце слота его надо было чистить.
Ну вот собственно и все. Две недели битвы увенчались успехом. Все, кто помогал, - спасибо.
1. Диспетчером задач ты утечки не найдешь.
2. Поздравляю! Но ошибку ты не нашел. QByteArrea у тебя уничтожается. Теперь падать у тебя будет где-то в другом месте и, возможно, не сейчас, а через неделю или месяц. А может и в этом.


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 09, 2017, 16:10
1. Диспетчером задач ты утечки не найдешь.
2. Поздравляю! Но ошибку ты не нашел. QByteArrea у тебя уничтожается. Теперь падать у тебя будет где-то в другом месте и, возможно, не сейчас, а через неделю или месяц. А может и в этом.

Первое утверждение бессмысленно. По факту нашел. Мелкие утечки остались. Но результат таков: Когда я приступил, программа могла обработать примерно 6 часов данных. Теперь она по факту обрабатывает 10 дней и прогноз, судя по размерам приложений - примерно 70. Итого я сократил утечки на два порядка. Точнее диспетчер действительно не поможет, но это уже не столь актуально. Разберусь постепенно.
А что до второго, это была не единственная ошибка. Но она тоже была.


Название: Re: Нужен совет по отладке
Отправлено: Авварон от Июнь 09, 2017, 16:42
1) диспетчер не показывает потребление памяти
2) это не ошибка


Название: Re: Нужен совет по отладке
Отправлено: Igors от Июнь 09, 2017, 16:43
К сожалению (для Вас) Пантер скорее всего прав - очень похоже что Вы не решили проблему, а загнали ее в "хронь". Чем чаще падает - тем лучше, самый мерзкий баг - тот что возникает в году раз


Название: Re: Нужен совет по отладке
Отправлено: Ced от Июнь 11, 2017, 02:03
Программа проработала непрерывно двое суток. За это время было выполнено больше миллиона циклов обработки данных. Это дает мне основание считать. что  проблема таки решена. А что до памяти, диспетчер показывает память, занимаемую каждым приложением с точностью до 1 КБт. В моем случае этого оказалось достаточно.


Название: Re: Нужен совет по отладке
Отправлено: kuzulis от Июнь 11, 2017, 13:19
Ну, у Вас может быть и проработало, а вот у конечного пользователя может не проработать (так сойдутся звезды)...


Название: Re: Нужен совет по отладке
Отправлено: Igors от Июнь 12, 2017, 10:11
Программа проработала непрерывно двое суток. За это время было выполнено больше миллиона циклов обработки данных. Это дает мне основание считать...
Не дает. Читаем классику
Цитировать
Тестирование может показать наличие ошибок но не их отсутствие


Название: Re: Нужен совет по отладке
Отправлено: AzazelloAV от Июнь 26, 2017, 21:45
Программа проработала непрерывно двое суток. За это время было выполнено больше миллиона циклов обработки данных. Это дает мне основание считать. что  проблема таки решена. А что до памяти, диспетчер показывает память, занимаемую каждым приложением с точностью до 1 КБт. В моем случае этого оказалось достаточно.

А прикольно. Если есть какая-то последовательность действий, совершенно дурацкая, которая приводит к падению,  о которой знает только разработчик и её невозможно повторить...... Она будет повторена пользователем сразу.....

Я за вас говорить не буду. Но! Какое это счастье для меня, что программа падает. А вот когда не падает...... Ищи свищи.

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

Это к чему я. Жопа всё равно настанет........