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

[Ced]

Код:

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КБайт.
У меня уже вывих мозга. Может кто посоветует, где искать?

[Пантер]

Я советую смотреть в других местах. Погоняй под валгриндом.

[Ced]

Я советую смотреть в других местах. Погоняй под валгриндом.

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

[Пантер]

http://valgrind.org/

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

[Ced]

http://valgrind.org/

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

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

[Igors]

Операция нормально выполняется 16810 раз и падает на pSocket->write (arrBlock);

Нужно постараться извлечь как можно больше из "места падения", что видно в отладчике, а не так себе просто "падает" и все. Возможно писать arrBlock сначала в файл чтобы потом его спокойно проверить. В общем найти "кто испорчен", потом уже как/когда

[Ced]

Операция нормально выполняется 16810 раз и падает на pSocket->write (arrBlock);

Нужно постараться извлечь как можно больше из "места падения", что видно в отладчике, а не так себе просто "падает" и все. Возможно писать arrBlock сначала в файл чтобы потом его спокойно проверить. В общем найти "кто испорчен", потом уже как/когда

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

[Пантер]

Ошибка может быть совершенно в другом месте.

[Ced]

Ошибка может быть совершенно в другом месте.

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

[Old]

Операция нормально выполняется 16810 раз и падает на pSocket->write (arrBlock);

Куда указывает указатель pSocket в момент падения?

[Ced]

Операция нормально выполняется 16810 раз и падает на pSocket->write (arrBlock);

Куда указывает указатель pSocket в момент падения?

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

[Ced]

Операция нормально выполняется 16810 раз и падает на pSocket->write (arrBlock);

Куда указывает указатель pSocket в момент падения?

Вышел на место падения пока адрес сокета такой

   
            clientSocket   @0x7fe3b618   QTcpSocket
               [QAbstractSocket]   @0x15f97928   QAbstractSocket
                  [QIODevice]   @0x15f97928   QIODevice
                  staticMetaObject   @0x67fb3104   QMetaObject
               staticMetaObject   @0x67fee15c   QMetaObject

Сейчас пройду до падения

[Igors]

И не совсем понимаю, а как содержание arrBlock может валить write? Иначе говоря, а что там искать?

Начинать нужно с самого внимательного обзора места падения в отладчике. На какой машинной команде вылет? Какой строке кода она соответствует в отладчике? Посмотреть this и др указатели/ссылки, может они калечные. Повторюсь - найти "кто испорчен", дальше ставить условный breakpoint и ловить (да, как правило ошибки далеко от этого места)

[Ced]

И не совсем понимаю, а как содержание arrBlock может валить write? Иначе говоря, а что там искать?

Начинать нужно с самого внимательного обзора места падения в отладчике. На какой машинной команде вылет? Какой строке кода она соответствует в отладчике? Посмотреть this и др указатели/ссылки, может они калечные. Повторюсь - найти "кто испорчен", дальше ставить условный breakpoint и ловить (да, как правило ошибки далеко от этого места)

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

[Ced]

Такое поведение наводит на мысль о нарушении границ отведенных областей памяти. И, как тут уже говорено, не в точке падения. И даже не факт, что в том цикле, где происходит падение. Может кто посоветует средство анализа работы с памятью под винду?