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

[Igors]

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

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

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

[Ced]

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

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

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

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

[Ced]

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

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

[Ced]

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

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

[kuzulis]

Просто не нужно плодить потоки и внимательно и аккуратно все делать... И тогда не будет никаких утечек и прочих нехороших вещей.

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

[Ced]

Просто не нужно плодить потоки и внимательно и аккуратно все делать... И тогда не будет никаких утечек и прочих нехороших вещей.

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

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

[Пантер]

Еще совет - замени указатели на "умные" указатели (std::unique_ptr, std::shared_ptr)

[Ced]

Еще совет - замени указатели на "умные" указатели (std::unique_ptr, std::shared_ptr)

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

[Пантер]

1. Уменьшает утечки памяти.
2. Не дает работать с указателями вникуда.

[Ced]

1. Уменьшает утечки памяти.
2. Не дает работать с указателями вникуда.

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

[Ced]

Подскажите пожалуйста, какова максимальная длина QByteArray для 32-битной операционки?

[kambala]

1. Уменьшает утечки памяти.
2. Не дает работать с указателями вникуда.

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

1 — просто утечка, 2 — потенциальный краш

Подскажите пожалуйста, какова максимальная длина QByteArray для 32-битной операционки?

INT_MAX, скорее всего 32767

[Old]

Подскажите пожалуйста, какова максимальная длина QByteArray для 32-битной операционки?

Под вендой упретесь в 2Гб.

[Ced]

А такая операция допустима?

Код:

List<x *>  a;
List<x *>  b;
......

a = b

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

[Old]

Операция то допустима, вы получите второй список с указателями на те-же самые объекты x.
Вы потом как эти объекты освобождаете? Повторных освобождений не делаете?