Как вызвать exec* без утечки памяти?

Когда вызывается функция семейства exec, то параметры копируются в память нового процесса, который замещает текущий без возможности возврата.

Соответственно, если параметры выделены на куче - формально происходит утечка памяти

?????

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

Вся память, выделенная в этом процессе ранее, освобождается.

Но не программистом, а системой. Соответственно все счетчики памяти, пользовательские или valgrind’овские считают что это lost.

switch(fork()) {
    case -1 : exit(1);
    case 0 :
       char ** args = allocate_args(...);
       execl(args[0], args);
       // never reached if started;
    default:
       ...
}

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

У тебя есть форк, который создает новый процесс с той же таблицой страниц. Дальше ты вызываешь exec*, который сначала проверяет останется ли у тебя 3/4 на стеке для запуска бинарника и подсчитывает количество аргументов. Если все ок, то exec копирует параметры себе в структуру(binprm или как-то так называется, лень искать), ну и дальше уже в свою vma начинает копировать бинарник с последующим началом исполнения. Команды на 3.5Гб быть не может, длинна пути файла тоже лимитирована, аргументы окружения тоже лимитированы. После удачного запуска можешь почистить аргументы в родительском процессе, если выделил их в хипе.

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

Во. А если память была выделена в родительском процессе до форка - форк не создаст ее копию когда я к ней обращусь при использовании в качестве аргуметов в exec?

Создаст, если освободите в родительском процессе. CoW же.

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

Вы из тех, кто перед exit() делаете много операций, чтобы освободить всю выделенную ранее память?

команда формально может быть до 3.5 Гб длиной, а стек всего метр-4

Так аргументы команды же на стек в итоге и складываются, лул.

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

это правильно

тупняк какой-то

с точки зрения … анализа

с моей точки зрения твои анализаторы говно, тк не учитывают, что exit() всё чистит. кто знает, какими ещё false positive они тебя дурят

Я в вашем примере, после комментария:

// never reached if started;

не увидил вызова exit(). Вот мне и стало интерестно. Сначала я подумал, что вы не делете exit() после exec(). А теперь, боюсь подумать, что вы между exec() и exit() в потомке суёте кучу free(), чтобы операционке, которая и так по каким-то причинам не смогла exec() стало ещё веселее от выделения памяти под CoW из-за free().

не увидил вызова exit()

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

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

Это упрощенный пример без обработки ошибок. Речь о нормальном цикле работы программы.

Формально, ресурс аллоцирован программистом, но не был освобожден им.

Формально ресурс был освобождён успешным вызовом execl. Баги анализаторов posix не колышут.