#c #memory-leaks #sdl #valgrind
#c #утечки памяти #sdl #valgrind
Вопрос:
Я пишу очень простое SDL-приложение, но когда я запускаю его через valgrind, оно сообщает о нескольких потерянных блоках, по-видимому, связанных с библиотекой SDL (прежде чем вы спросите об этом, я вызываю SDL_Quit, или, точнее, я вызываю atexit(SDL_Quit) ). Вот пример:
==2525== 192 (16 direct, 176 indirect) bytes in 1 blocks are definitely lost in loss record 107 of 131
==2525== at 0x4C25502: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2525== by 0x644244A: ??? (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x6442989: ??? (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x64440A2: ??? (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x6444915: _XlcCreateLC (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x6462B5F: _XlcDefaultLoader (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x644C325: _XOpenLC (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x644C467: _XlcCurrentLC (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x644C4BD: XSetLocaleModifiers (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x4E69EED: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==2525== by 0x4E6A57F: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==2525== by 0x4E59E00: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.11.3)
Я искал здесь, в StackOverflow, и нашел похожий вопрос. Ответ заключался в том, что, по-видимому, в библиотеке выделено несколько небольших буферов, которые авторы никогда не хотят освобождать. Мой вопрос в том, какова мотивация такого подхода? Зачем что-то выделять, а затем намеренно не free() использовать?
Комментарии:
1. Возможно, это ошибка в библиотеке? Не весь код написан идеально. Очень возможно, что они случайно забыли освободить там часть памяти, поскольку это очень большая библиотека.
2. Не хочу делать двойной комментарий, но я забыл добавить: если это действительно утечка памяти, возможно, вы захотите сообщить об этом разработчикам SDL. Однако Eelke действительно указывает на то, что они, возможно, просто ждут до самого конца, чтобы фактически освободить ее.
Ответ №1:
Если буферы необходимы до конца программы, нет необходимости освобождать их. При выходе программы вся память, которую она использовала, все равно освобождается операционной системой. Если бы программа потрудилась освободить блоки перед выходом, это только замедлило бы выход из программы.
Комментарии:
1. Вероятно, это и есть причина, но я думаю, что это никудышная причина, особенно для библиотеки, и я бы никому не советовал ей следовать. Во-первых, это плохо, потому что операционные системы не гарантированно освобождают память; как правило, более старые или те, у которых нет диспетчера памяти, этого не сделают. Во-вторых, это плохо именно из-за этого вопроса: такие инструменты, как Valgrind, приведут к истерике, что очень затруднит отладку вашего собственного кода. В-третьих, это плохо для библиотеки, потому что завершение работы библиотеки не обязательно является завершением процесса. Если клиент просит вашу библиотеку завершить работу, вежливо освободить всю память.
2. Я согласен, что это не очень хорошая практика, особенно для библиотеки, я просто говорил, что это не обязательно то, о чем стоит беспокоиться. Многие приложения не очищают там отдельные файлы, потому что беспокоиться о том, когда их освобождать, не стоит.