Из управления памятью, повреждения "кучи" и C++

У нас когда-то была ошибка, которая уклонилась от всех регулярных методов, valgrind, очистите и т.д. Катастрофический отказ только когда-либо происходил на машинах с большой памятью и только на больших наборах входных данных.

В конечном счете мы отследили его вниз использование контрольных точек отладчика. Я попытаюсь описать процедуру здесь:

1) Находят причину отказа. Это смотрит от Вашего примера кода, что память для "exampleString" повреждается и так не может быть записана в. Давайте продолжим это предположение.

2) Набор точка останова в последнем известном местоположении, что "exampleString" используется или изменяется без любой проблемы.

3) Добавляют контрольную точку к элементу данных 'exampleString'. С моей версией g ++, строка хранится в _M_dataplus._M_p. Мы хотим знать, когда этот элемент данных изменяется. Техника GDB для этого:

(gdb) p &exampleString._M_dataplus._M_p
$3 = (char **) 0xbfccc2d8
(gdb)  watch *$3
Hardware watchpoint 1: *$3

я, очевидно, использую Linux с g ++ и gdb здесь, но я полагаю, что контрольные точки памяти доступны с большинством отладчиков.

4) Продолжаются, пока контрольная точка не инициирована:

Continuing.
Hardware watchpoint 2: *$3

Old value = 0xb7ec2604 ""
New value = 0x804a014 ""
0xb7e70a1c in std::string::_M_mutate () from /usr/lib/libstdc++.so.6
(gdb) where

команда gdb where даст заднюю трассировку, показывающую, что привело к модификации. Это - или совершенно легальная модификация, в этом случае только продолжите - или если Вы удачливы, что это будет модификация из-за повреждения памяти. В последнем случае необходимо теперь смочь рассмотреть код, который является действительно порождение проблемы, и, надо надеяться, зафиксируйте его.

причиной нашей ошибки был доступ к массиву с отрицательным индексом. Индекс был результатом броска указателя на 'интервал' modulos размер массива. Ошибка была пропущена valgrind и др. как адреса памяти, выделенные, когда выполнение под теми инструментами никогда не было" > MAX_INT" и поэтому никогда не приводило к отрицательному индексу.

Это могло быть повреждение "кучи", но это столь же вероятно быть повреждением стека. Право Jim. Нам действительно нужно немного больше контекста. Те две строки источника не говорят нам очень в изоляции. Могло быть любое количество вещей, вызывающих это (который является реальной радостью C/C++).

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

О, если Вы хотите знать, как отладить проблему, это просто. Во-первых, получите мертвую курицу. Затем начинают встряхивать его .

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

1. Становятся удобными в отладчике.
2. Начинают затаптывать вокруг в отладчике, чтобы видеть, можно ли найти что-нибудь, что выглядит подозрительным. Проверьте особенно для наблюдения то, что происходит во время exampleString = hello; строка.
3. Проверка для проверки это на самом деле отказывает на exampleString = hello; строка, и не при выходе из некоторого блока включения (который мог заставить деструкторы стрелять).
4. Проверка любое волшебство указателя Вы могли бы делать. Адресная арифметика с указателями, кастинг, и т.д.
5. Проверка все Ваши выделения и освобождение для проверки они подобраны (никакое двойное освобождение).
6. Удостоверяются, что Вы не возвращаете ссылок или указателей на объекты на стеке.

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

Некоторые места для запуска:

, Если Вы находитесь на окнах, и использующий Visual C++ 6 (я надеюсь богу, никто все еще не использует его в эти дни) это - реализация станд.:: строка не ориентирована на многопотоковое исполнение, и может привести к такого рода вещи.

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

На моем предыдущем рабочем месте мы использовали Compuware Boundschecker для помощи с этим. Это является коммерческим и очень дорогим, так может не быть опция.

Вот несколько свободных библиотек, которые могут быть несколько полезны

http://www.codeguru.com/cpp/misc/misc/memory/article.php/c3745/

http://www.codeproject.com/KB/cpp/MemLeakDetect.aspx

Hope, которая помогает. Повреждение памяти является местом sucky, чтобы быть в!

Код был просто примером того, где моя программа перестала работать (это было выделено на стеке, Jim). Я на самом деле не ищу, 'что я сделал неправильно', а скорее, 'как я диагностирую то, что я сделал неправильно'. Учите человека ловить рыбу и все это. Хотя смотря на вопрос, я не ясно дал понять достаточно. Слава Богу для функции редактирования.: ')

кроме того, я на самом деле зафиксировал станд.:: строковая проблема. Как? Путем замены его вектором, компиляцией, затем заменяя строку снова. Это было последовательно катастрофический отказ там и зафиксированный даже при том, что это... не могло. Там существует что-то противное, и я не уверен что. Я действительно хотел проверить одно время, я вручную выделяю память на "куче", хотя:

 this->map = new Area*[largestY + 1];
 for (int i = 0; i < largestY + 1; i++) {
     this->map[i] = new Area[largestX + 1];
 }

и удаление его:

for (int i = 0; i < largestY + 1; i++) {
    delete [] this->map[i];
}
delete [] this->map;

я не выделил 2-й массив с C++ прежде. Это, кажется, работает.

кроме того, я на самом деле зафиксировал станд.:: строковая проблема. Как? Путем замены его вектором, компиляцией, затем заменяя строку снова. Это последовательно отказывало там, и зафиксированный даже при том, что это... не могло. Там существует что-то противное, и я не уверен что.

, Который походит, Вы действительно потрясали курицу в нем. Если Вы не знаете , почему это работает теперь, то это все еще повреждено и в значительной степени гарантировано укусить Вас снова позже (после добавления еще большей сложности).

Один из методов отладки, которые я часто использую (кроме случаев самой экстремальной странности) должен разделить и завоевать. Если Ваша программа в настоящее время перестала работать с некоторой определенной ошибкой, то разделите ее пополам в некотором роде и посмотрите, имеет ли она все еще ту же ошибку. Очевидно, прием должен решить, где разделить Вашу программу!

Ваш пример, как дали не показывает достаточно контекста для определения, где ошибка могла бы быть. Если бы кто-либо еще должен был попробовать Ваш пример, то он хорошо работал бы. Так, в Вашей программе попытайтесь удалить такое количество дополнительного материала, который Вы не показали нам и видели, работает ли это затем. Если так, затем включите другой код назад понемногу, пока он не начнет перестать работать. Затем вещью, которую Вы просто добавили, является, вероятно, проблема.

Примечание, что, если Ваша программа является многопоточной, то у Вас, вероятно, есть большие проблемы. В противном случае затем необходимо смочь сузить его таким образом.Удачи!

Выполненный Очищают.

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

Это работает на уровне машинного кода, таким образом, у Вас не должно даже быть исходного кода.

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

Они думали, что мы отлаживали богов, но затем мы впускаем их на секрете, таким образом, они могли работать, Очищают, прежде чем мы должны были использовать их код. :-)

http://www-306.ibm.com/software/awdtools/purify/unix/

(Это довольно дорого, но у них есть бесплатная загрузка оценки)

Насколько я могу сказать, что Ваш код является правильным. Принятие exampleString является станд.:: строка, которая имеет объем класса как Вы, описывает, необходимо смочь инициализировать/присвоить его тот путь. Возможно, существует некоторая другая проблема? Возможно, отрывок фактического кода помог бы поместить его в контекст.

Вопрос: действительно ли exampleString является указателем на строковый объект, созданный с новым?

Ваш код, как я вижу, не имеет никаких ошибок. Как был сказан, больше контекста необходимо.

, Если Вы уже не попробовали, установите gdb (gcc отладчик) и скомпилируйте программу с-g. Это скомпилирует в отладочной информации, которую может использовать gdb. После того как у Вас есть установленный gdb, выполняет его с программой (gdb). Это является полезным cheatsheat для использования gdb.

Набор точка останова для функции, которая производит ошибку и видит, каково значение exampleString. Также сделайте то же для любого параметра, Вы являетесь передающими к exampleString. Это должно, по крайней мере, сказать Вам если станд.:: строки допустимы.

я нашел, что ответ от эта статья был хорошим руководством об указателях.

Кроме инструментов как Boundschecker или Purify, Ваш лучший выбор при решении проблем как это состоит в том, чтобы просто стать действительно хорошим в чтении кода и знакомиться с кодом, что Вы продолжаете работать.

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

, Если это помогает кому-либо, это - что-то, что Вы поправляетесь в том, как Вы приобретаете опыт.

Ваше выделение памяти для корректных взглядов массива, но удостоверяется, что Вы проверяете все места, где Вы получаете доступ к массиву также.