В работе участвовали:
Гильденберг Максим и Панкратов Семен Утечка памяти достаточно серьезная проблема возникающая при работе программы. Масштабность проявляется особенно при длительной работе программы, когда программа может исчерпать лимит выделения для нее памяти, а это приведет к очень нехорошим последствиям. Простейшая программа с утечкой памяти:
#include int main() < int* p = new int[2]; std::cout
- Библиотека CRT (Windows);
- Visual Leak Detector (Windows);
- Valgrid memchek (Linux);
- Как это устроено внутри.
- Более сложный пример. Результаты.
1 Обнаружение утечек с библиотекой CRT
Библиотека CRT доступна в операционной системе Windows, она у вас уже есть если вы используете Microsoft Visual Studio. Для подключения анализатора памяти достаточно добавить пару макросов и собрать проект в отладочном режиме:
// в начало файла с точкой входа: #define _CRTDBG_MAP_ALLOC #include #define DBG_NEW new( _NORMAL_BLOCK , __FILE__ , __LINE__ ) #define newDBG_NEW #include int main() < int* p = new int[2]; std::cout
Видно, что первая группа макросов добавляется в самое начало вашей программы. За счет этих макросов все обращения в функциям new, malloc, free и delete заменяются на другие версии, которые помимо выделения/освобождения памяти сохраняют дополнительную информацию (сколько и где было выделено). Макрос _CrtDumpMemoryLeaks добавляется в конец программы (перед завершением работы) и выводит информацию о текущем состоянии памяти.
Как Найти и Удалить Паразиты, Которые Забивают Память Телефона!!
Для приведенной выше программы в окно отладки будет выведено следующее:
Утечка была обнаружена, кроме того, нам показывают ее размер и даже строку кода где это случилось.
2 Использование Visual Leak Detector
VLD поставляется в виде плагина для Microsoft Visual Studio, для его установки:
1) Скачиваем с официального сайта Microsoft и устанавливаем.
2) Добавляем в свойствах проекта во «включаемые каталоги» путь к каталогу include:
C:ProgramFiles(x86)VisualLeakDetectorinclude .
3) Добавляем в свойствах проекта в Каталог библиотек для win32 или win64 : путь к катлогу lib:
C:ProgramFiles(x86)VisualLeakDetectorlibWin32 C:ProgramFiles(x86)VisualLeakDetectorlibWin64
4) Добавляем в начало главного файла ( main.cpp ) #include
Получается так:
#include #include int main() < int* p = new int[2]; std::cout
Все говото, утечки ищутся и выводятся в консоль отладки:
Видно, что VLD выводит информацию о стеке вызовов, но формат вывода крайне неудобный. Узнать в какой строке произошла утечка памяти совсем непросто.
3 Работа с Valgrind memcheck
Valgrind предоставляет множество инструментов для динамического анализа, поиском утечек памяти это не ограничивается. Работой с памятью занимается модуль memcheck. Для его использования необходимо:
100% ПЕРЕМЕСТИТЬ Приложения и Игры на КАРТУ ПАМЯТИ SD на ЛЮБОМ Телефоне ANDROID
1) Сстановить valgrind:
sudo apt install valgrind
2) Скомпилировать программу в debug-режиме и запустить ее через valgrind:
valgrind ./my_program
При таком запуске будет выведено сколько памяти было потеряно. Чтобы увидеть, где была выделена память, необходимо добавить опцию
—leak-check=full .
Результаты работы memcheck для нашего примера:
4 Как это устроено внутри
Подключение CRT приводит к оборачиванию функций работы с памятью в что-то такое:
__declspec(align(16)) struct SMVECTOR < union < __m128 mmv; struct < float x; float y; float z; float w; >; >; void* operator new(size_t size) < return (_aligned_malloc(size, 16)); >; void operator delete(void* ptr) < _aligned_free(ptr); >; void* operator new[](size_t size) < return (_aligned_malloc(size, 16)); >; void operator delete[](void* ptr) < _aligned_free(ptr); >; >;
Вы могли бы сделать это сами, но это непросто, а ведь надо еще разобрать все возможные ошибки при работе с памятью — free вместо delete , выделение объекта одного типа, а удаление — другого и так далее.
Да и зачем этим заниматься если его готовый CRT? В свою очередь, Visual Leak Detector представляет собой обертку над CRT.
Утилита Valgrind работает совсем иначе — ей не требуется модифировать исходный код вашей программы. Вместо этого программа запускается на виртуальном (моделируемом) процессоре в виртуальном окружении. Это окружение точно знает сколько памяти потребила программа, а процессор — в каких инструкциях эта память была запрошена.
За счет этого valgrind позволяет не только обнаружить утечки памяти, но и получить статистику кэш-попаданий (модуль cachegrind), например. Однако, тут внутреннее устройство valgrind показано крайне упрощенно, а на самом деле все гораздо сложнее. Тем не менее, это один из лучших инструментов поиска утечек в мире.
4 Более сложный пример
Возможно, вам кажется что проблем с поиском утечек не возникает, тогда посмотрите такой пример:
#include class Animal < char *name; public: Animal() < name = new char[50]; std::cout /*virtual */~Animal() < delete name; std::cout virtual void say() = 0; >; class Cat : public Animal < public: Cat() < std::cout ~Cat() < std::cout virtual void say() < std::cout protected: char *color; >; int main() < Animal* p = new Cat(); p->say(); //delete p; return 0; >
Сколько времени у вас уйдет на поиск всех утечек? Ведь после возврата строки delete p в программе появятся другие утечки. Для начала — не будет вызывать деструктор ~Cat() ведь деструктор ~Animal() объявлен невиртуальным. После исправления этой ошибки — мы получим еще одну, ведь в классе Cat память выделяется через new , а освобождается через free .
Результаты применения всех трех рассмотренных инструментов примерно одинаковы (разве что VLD не выводит информацию о строке возникновения ошибки). Ниже приведен вывод valgring memcheck:
Видно, что обнаруживается 3 утечки, так как на 3 аллокации не приходится ни одной операции освобождения. После добавления delete в функцию main получаем одну утечку. Теперь на 3 аллокации приходится две операции освобождения. Найдена лишь одна утечка, однако на самом деле — вообще не вызывается деструктор ~Cat() , поэтому после замены free на delete в нем — результат работы не изменится. А вот после добавления виртуального деструктора — утечек найдено не будет.
Понятно, что описанные инструменты сильно упрощают жизнь программисту. Найти без них течки памяти в чужом коде из 10 тысяч строк кода — задача крайне сложная, а с ними — решается элементарно. Однако, вывод результатов их работы очень неинформативный. Сравните полученные результаты с выводом статических анализаторов (в обоих статьях используются одинаковые примеры).
Источник: pro-prof.com
Что такое «Другое» в памяти телефона, и почему оно занимает столько места
В памяти любого смартфона есть категория «Другое». Сегодня мы разберемся, что это, и почему она занимает столько места. Ну и, конечно, попробуем уменьшить размер этой категории.
Как бы производители ни старались увеличивать объем памяти своих смартфонов, ее нехватка всегда будет оставаться извечной головной болью любого пользователя. Конечно, особенно остро эта проблема стоит у владельцев относительно недорогих смартфонов с 64, 32 и тем более 16 Гбайт встроенной памяти, но с ней хорошо знакомы и пользователи более дорогих устройств.
Расположение кода программы в памяти компьютера
Прочитал, что программы скомпилированные на VS имеют базовый адрес в памяти 0x00400000. Стало интересно как в памяти буду располагаться 2 программы. Написал, запустил и обе пишут адрес 0x00400000, но как? почему две разные программы располагаются по 1 адресу? разве такое возможно?
Отслеживать
9,639 4 4 золотых знака 21 21 серебряный знак 35 35 бронзовых знаков
задан 17 фев 2016 в 13:33
504 2 2 серебряных знака 15 15 бронзовых знаков
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Это виртуальная память, которая у каждого процесса своя. В итоге, два процесса могут быть загружены по виртуальному адресу 0x400000 и не мешать друг-другу. Есть физическая память, допустим 4 гига — от 0x00000000 до 0xFFFFFFFF. Ядро операционной системы выделяет, например, физический кусок 0x70000000 — 0x80000000 для процесса. И изнутри процесс видит эту память как 0x400000 — 0x10400000.
Для второго процесса выделается 0x8000000-0x90000000, а изнутри он видит те же адреса, что и первый.
Отслеживать
ответ дан 17 фев 2016 в 13:39
Владимир Мартьянов Владимир Мартьянов
9,639 4 4 золотых знака 21 21 серебряный знак 35 35 бронзовых знаков
а как допустим узнать его реальное, а не виртуальное расположение в памяти? и как вообще понять «виртуальная память»?
17 фев 2016 в 13:41
Есть физическая память, допустим 4 гига — от 0x00000000 до 0xFFFFFFFF. Ядро операционной системы выделяет, например, физический кусок 0x70000000 — 0x80000000 для процесса. И изнутри процесс видит эту память как 0x400000 — 0x10400000. Для второго процесса выделается 0x8000000-0x90000000, а изнутри он видит те же адреса. Зачем вам, кстати, физические адреса?
17 фев 2016 в 13:46
спасибо большое. понял, принял, разобрался)
17 фев 2016 в 13:48
17 фев 2016 в 13:50
«Реальное» положение не имеет особого смысла для программиста. Например, страница виртуальной памяти может быть вытеснена на диск, и потом загружена по другим физическим адресам.
Источник: ru.stackoverflow.com