LINUX.ORG.RU

Санитайзер памяти для С++

 


0

5

Всем привет!

Кто знает, как такое может быть? Собираю тестовый пример с санитайзером памяти:


int main (int argc, char** argv) {
  char *p = new char[1024];
  sleep (20000);
  delete [] p;
  return 0;
}

Собираю приложение так:
g++ test.cpp -o test -fsanitize=address

После запуска в `ps aux | grep test` вижу, что приложение запросило 20Тб виртуальной памяти

`g++ -version`:
`g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0`

Как так может быть? Кроме того я не могу запросить сам такие объемы при желании

Ответ на: комментарий от sotlef

Это и есть адекватный вывод. Зачем ты вообще смотришь на виртуальную память?

На Win 10 точно так же: https://imgur.com/a/t7ltfFZ

17,7 терабайт виртуальной памяти

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от fsb4000

Почему он адекватный, я не понимаю? Как мне оценить потребление памяти в такой сборке для реального приложения.

sotlef
() автор топика
Ответ на: комментарий от sotlef

не используй -fsanitize=address для реального приложения. Используй для тестов.

Вот закрыли такой же вопрос как не баг: https://github.com/google/sanitizers/issues/704

The newer one consumes 20t.
And that is normal, see https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm
fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 2)
Ответ на: комментарий от fsb4000

Все, понял. Большое спасибо!, вопрос закрыт.

sotlef
() автор топика

На 64разрядной системе каждому процессу доступно виртуальное адресное пространство размером минимум 2^63 бит.

pon4ik ★★★★★
()

Санитайзеры - зло. Я как-то бодался с одним говноприложением, которое юзало boost.asio и дедлочилось, собрал буст и приложение с тред-санитайзером ваще стало сегфолтиться. Ну я по-старинке методом пристального взгляда нашёл косяк в бусте и пофиксил. А вот санитайзер мне не помог.

Urechis_Unicinctus
()

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от annulen

Какой смысл смотреть rss? Если система скинет страницы процесса в своп, то это ее дело - на это мы практически повлиять не можем. А вот сколько процесс потребляет виртуальной памяти - это важно для замеров. Просто в такой ситуации выходит, что потребление памяти с санитайзером памяти не получится, смотреть его надо в релизной сборке.

sotlef
() автор топика
Ответ на: комментарий от sotlef

Какой смысл смотреть rss?

Ну, например, чтобы узнать потребление памяти процессом?

А вот сколько процесс потребляет виртуальной памяти - это важно для замеров.

Для каких замеров? Эта величина не имеет почти никакого практического значения, особенно если процесс использует динамические библиотеки и/или mmap’ит файлы

annulen ★★★★★
()
Ответ на: комментарий от sotlef

Если система скинет страницы процесса в своп, то это ее дело - на это мы практически повлиять не можем.

Да. А если проводить замеры, когда памяти в системе достаточно для нормальнеой работы, то получится реальная величина.

Еще можно замерять размер кучи, что бывает полезно, если хочется выявить разного рода утечки. RSS это по сути куча + стэк + загруженный в память код.

annulen ★★★★★
()
Ответ на: комментарий от annulen

Какой-то сюр теоретический пишете. Есть приложение, которое написал я. Я знаю, что не использую mmap-инг, количество загруженных библиотек от версии к версии разрабатываемого ПО одинаково и имеют одни и те же версии. Приложение в штатной работе предполагает, что будет запрашивать в куче на сервере в продакшене определенный объем данных. Для некоторых моделей ожидаем 16Гб, для других 32Гб, для других 512Гб и так далее. Т.е. на страницы кода мы вообще не обращаем внимание, так как их относительный размер мизерный - так что shared libraries тут мимо!

Итак: на одной машине у нас запущена много-много дней старая версия ПО, потребляет 16Гб VRAM и 2Гб RSS. На другой машине эта же модель сразу после запуска ПО потребляет 16Гб VRAM и 16Гб RSS. Девопс пишет, почему новая версия потребляет 16Гб RSS, а старая - только 2Гб RSS?

И вот нахрена мне смотреть RSS? И приходится такому-же объяснять, что не нужно смотреть на RSS - за много-много дней редкоиспользуемые страницы памяти на старой системе со старой версией ПО были слиты в своп (который забит на 14Гб, сюрприз!), а в новой версии страницы все еще находятся в RSS и при последующих запросах аналогично при необходимости будут сливаться в своп, когда потребуется место в резидентной памяти.

Когда речь идет об оценке выделения динамической памяти под данные, RSS тут вообще ничего не показывает - даже если процесс ничего не делает, он сейчас будет занимать 16Гб в RSS, а через 5 минут от работы другого процесса будет занимать 2Гб в RSS. Хотя VM дает адекватно понять расход

sotlef
() автор топика
Последнее исправление: sotlef (всего исправлений: 3)
Ответ на: комментарий от sotlef

Для некоторых моделей ожидаем 16Гб, для других 32Гб, для других 512Гб и так далее.

Не ну с такими объемами конечно можно забить на страницы с кодом. А на моих железках типичная ситуация что оперативки 100 мб, свопа нет в принципе, а vm за 300, и это прекрасно работает :)

И вот нахрена мне смотреть RSS? И приходится такому-же объяснять, что не нужно смотреть на RSS - за много-много дней редкоиспользуемые страницы памяти на старой системе со старой версией ПО были слиты в своп (который забит на 14Гб, сюрприз!), а в новой версии страницы все еще находятся в RSS и при последующих запросах аналогично при необходимости будут сливаться в своп, когда потребуется место в резидентной памяти.

ИМХО если в продакшен-системе идет такой массовый своппинг то это скорее авария, чем штатный режим работы. Хотя я хз что у вас там за задачи

annulen ★★★★★
()
Ответ на: комментарий от sotlef

Адекватный расход тут покажет rss + своп, а vm это все равно оценка сверху, возможно сильно сверху.

annulen ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.