Трассировка повреждения памяти на производстве сервер Linux
Причины предупреждения уже описаны, но как Вы зафиксировали бы предупреждение? Необходимо изолировать или класс или виртуального участника.
class B
{
protected virtual void Foo() { }
}
class A : B
{
public A()
{
Foo(); // warning here
}
}
можно изолировать класс A:
sealed class A : B
{
public A()
{
Foo(); // no warning
}
}
Или можно изолировать метод Foo:
class A : B
{
public A()
{
Foo(); // no warning
}
protected sealed override void Foo()
{
base.Foo();
}
}
8 ответов
Ребята, мне удалось найти источник ошибки. Однако я нашел его на сервере сцены с помощью helgrind / DRD / tsan - между несколькими потоками существовала передача данных, что привело к повреждению памяти. Ключевым моментом было использование правильного подавления valgrind, поскольку эти инструменты показали слишком много ложных срабатываний. Тем не менее, я действительно не знаю, как это можно обнаружить на рабочем сервере без значительных замедлений ...
Да, проблемы с повреждением памяти C / C ++ серьезны. Я также несколько раз использовал valgrind, иногда он выявлял проблему, а иногда нет.
При проверке вывода valgrind не стоит слишком быстро игнорировать его результат. Иногда по прошествии значительного времени вы увидите, что valgrind дал вам ключ к разгадке, но вы проигнорировали его.
Другой совет - сравнить изменения кода из ранее известной стабильной версии. Это не проблема, если вы используете какую-то систему управления версиями исходного кода (например, svn). Изучите все функции, связанные с памятью (например, memcpy, memset, sprintf, new, delete / delete []).
Вы пробовали -fmudflap ? (прокрутите несколько строк вверх, чтобы увидеть доступные параметры).
вы можете попробовать IBM purify, но я боюсь, что это не открытый исходный код ..
Скомпилируйте свою программу с помощью gcc 4.1 и переключателя -fstack-protector-all. Если повреждение памяти вызвано разбиением стека, он должен его обнаружить. Возможно, вам придется поиграть с некоторыми дополнительными параметрами SSP.
Инструменты Google Perftools --- с открытым исходным кодом --- могут помочь, см. проверка кучи документация.
Я не уверен, может ли он отловить вашу конкретную ошибку, но MALLOC_CHECK_ переменная среды ( malloc страница руководства ) включает дополнительную проверку в реализации Linux malloc по умолчанию и обычно не требует значительных затрат времени выполнения.
Попробуйте это: http://www.hexco.de/rmdebug/ Я использовал его широко, он мало влияет на производительность (в основном влияет на количество оперативной памяти), но алгоритм распределения тот же. Этого всегда достаточно, чтобы найти какие-либо ошибки распределения. Ваша программа выйдет из строя, как только возникнет ошибка, и будет вести подробный журнал.