С/С++ Portal | Программирование

В Linux закрытие файлового дескриптора не всегда означает, что память освобождена. Это классический источник тихих утечек памяти в долго живущих процессах. Почему так? Всё упирается в довольно мощное архитектурное решение вокруг двух системных вызовов: mmap и его пары munmap. Когда ты вызываешь mmap(), ядро связывает файл на диске с участком виртуальной памяти процесса. В ответ ты получаешь указатель и можешь читать и писать как в обычный массив. Но close() разрывает только связь с файловым дескриптором. Сам mapping при этом остаётся. Чтобы реально освободить виртуальное адресное пространство, нужен отдельный вызов — munmap(). Это прямой антипод mmap(), который говорит ядру:

всё, с этим регионом памяти покончено.

    
        int munmap(void *addr, size_t length);{}
    

Один вызов создаёт mapping, другой его разрушает. Прозрачно и логично. Ниже минимальный пример на C, где показан полный цикл использования. Обрати внимание что munmap() вызывается до close(). После вызова munmap доступ к mapped_memory приведёт к SIGSEGV.

    
        #include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>

int main() {
  int fd = open("test.file", O_RDWR | O_CREAT, 0666);
  ftruncate(fd, 4096); // убеждаемся, что размер файла кратен странице

  // маппим файл в память
  char *map = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
  strcpy(map, "Hello from mapped memory!");

  // явно освобождаем mapping
  munmap(map, 4096);

  // теперь закрываем дескриптор
  close(fd);

  return 0;
}{}
    

И важно то что, это не баг, а фича. Разделение close() и munmap() даёт гибкость. Программа может закрыть файл для дальнейших операций ввода-вывода, но оставить его содержимое доступным через mapping с минимальными накладными расходами. Такой подход лежит в основе многих системных механизмов:

загрузка и выгрузка динамических библиотек (.so), высокопроизводительный zero-copy I/O в серверах и базах данных, организация общей памяти между процессами.

Если работаешь с низкоуровневым I/O, стоит держать это в голове. 👉 @Cpportal

Все надоело и пропал интерес, чувствуешь себя амебой и хочется только залипать в телефоне. Бывает? Homo Manifestans — канал для айтишников, у которых периодически опускаются руки и отключается мозг, ибо переработки и постоянная тревожность не приводят к другим исходам 🤗 ✓ Как научиться отвлекаться от работы и отдыхать? ✓ Как совместить кучу рабочих задач и время с семьей? ✓ Как справиться с прокрастинацией? ✓ Как не растерять запал, даже если начальник и коллеги 💩 и кажется, что ничего не выходит? Подписывайтесь на канал @vadimpetrovpsi и научитесь работать без упахивания, выгорания и ущерба для личной жизни! Псс. Заходите в закреп — там много полезного, и даже бесплатный мини-курс по выходу из апатии: 👉 https://t.me/+yEjaFz-hY1EyZGJi

Файл-органайзер на C, который автоматически разбирает бардак в папке Downloads. Просто запускаешь и он сам раскидывает файлы по папкам: картинки в Images/, документы в Documents/, видео в Videos/ и так далее. 👉 @Cpportal

Твой браузерный JavaScript-движок генерирует новый машинный код прямо во время выполнения программы. Но Linux запрещает страницы памяти, которые одновременно и writable, и executable. 🤔 Как рантаймы и виртуальные машины вроде JVM генерируют код на лету и при этом не нарушают это правило безопасности? Ответ простой: хитрый системный вызов mprotect (номер 10 на x86_64). Современные процессоры имеют аппаратную поддержку, позволяющую операционным системам enforcing ключевую политику безопасности W^X (Write XOR Execute). В Linux это значит, что страница памяти может быть либо writable, либо executable. Никогда оба сразу. Эта защита отсекает целый класс эксплойтов. Но она создает проблему для JIT-компиляторов, которым нужно генерировать исполняемый код во время выполнения программы. Решение выглядит как трехходовка с ядром через mprotect:

Выделение памяти: получаем память через mmap с правами PROT_READ | PROT_WRITE Запись: JIT пишет в эту память свежесгенерированный машинный код, как в обычный буфер Защита: вызываем mprotect() и меняем права на PROT_READ | PROT_EXEC

Права на запись убираются, и теперь код можно безопасно выполнить. При этом эта область памяти никогда не находится в состоянии RWX. Минимальный пример, который создает и запускает функцию во время выполнения: Этот код пишет одну инструкцию ret (0xc3) в буфер, делает память исполняемой с помощью mprotect и вызывает ее как функцию.

    
        #include <stdio.h>
#include <string.h>
#include <sys/mman.h>

int main() {
    // Выделяем одну страницу памяти
    char *mem = mmap(NULL, 4096, PROT_READ | PROT_WRITE,
                     MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);

    // Копируем одну инструкцию "return"
    memcpy(mem, "\xc3", 1);

    // Делаем память исполняемой (и только для чтения)
    mprotect(mem, 4096, PROT_READ | PROT_EXEC);

    // Создаем указатель на функцию и вызываем "функцию"
    void (*func)() = (void (*)())mem;
    printf("Calling generated code...\n");
    func();
    printf("Returned successfully!\n");

    return 0;
}{}
    

Но mprotect важен не только для JIT. Это один из фундаментальных механизмов безопасности современных систем. Он обеспечивает Data Execution Prevention (W^X), гарантируя, что сегменты с данными нельзя выполнить как код. Это блокирует атаки через buffer overflow, где злоумышленник пытается вставить и исполнить свой код в данных. Также через него создают guard-pages - области памяти с PROT_NONE рядом со стеками. Если стек переполняется и пересекает guard-page, программа сразу падает вместо того, чтобы тихо портить память или запускать чужой код. Вот почему mprotect одновременно и инструмент для JIT-магии, и кирпич в фундаменте безопасности операционных систем. 👉 @Cpportal

Если твой код для обработки файла на 10 ГБ выглядит как read(fd, buf, ...) в цикле, то ты тратишь память впустую и убиваешь производительность. Есть способ получше. mmap позволяет работать даже со 100-гигабайтным файлом так, будто это просто огромный массив в памяти, даже если у тебя всего несколько мегабайт RAM. Вместо копирования данных из ядра в процесс через read, mmap просто мапит файл прямо в виртуальное адресное пространство процесса. Ты получаешь указатель, а ядро делает всю грязную работу. Страницы файла подгружаются в память только тогда, когда ты реально к ним обращаешься. Это называется отложенная загрузка страниц (on-demand paging). В итоге код проще, а накладных данных нет. Вот пример mmap в деле: мы отображаем файл в память и сразу можем читать любую его часть, используя указатель как обычный массив char*. Всё ввод-вывод за тебя делает ОС.

    
        #include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <stdio.h>
#include <unistd.h>

int main(int argc, char **argv) {
  int fd = open(argv[1], O_RDONLY);
  struct stat s;
  fstat(fd, &s);

  // Мапим весь файл в адресное пространство процесса
  char *data = mmap(NULL, s.st_size, PROT_READ, MAP_PRIVATE, fd, 0);

  if (data != MAP_FAILED) {
    // Теперь работаем с файлом как с огромным массивом!
    printf("Первый символ: %c\n", data[0]);
    printf("Символ посередине: %c\n", data[s.st_size / 2]);
  }

  munmap(data, s.st_size);
  close(fd);
  return 0;
}{}
    

Вся мощь mmap раскрывается через флаги. Два самых важных: • MAP_PRIVATE — приватное копирование при записи. Изменения не пишутся обратно в файл и не видны другим процессам. Идеально, если нужно только читать. • MAP_SHARED — изменения попадают обратно в файл и видны всем другим процессам, которые тоже мапят этот файл. Этот механизм настолько базовый, что Linux использует его повсюду: • так динамический линкер загружает .so библиотеки • используется для быстрой разделяемой памяти между процессами • лежит в основе баз данных и поисковых движков, которые работают с огромными объемами данных mmap — один из ключевых механизмов современных ОС. 👉 @Cpportal

⚡️ На Stepik вышел курс по Linux Ребята сделали крутейший курс по Linux, где понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами обучают работе с этой ОС Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой). После прохождения вы получите сертификат, который можно добавить в резюме. Есть бесплатные демо-уроки для ознакомления. В ближайшие 48ч курс доступен со скидкой 25% по промокоду «LINUXTG25»: открыть курс на Stepik

Люди обычно пишут ботов для Discord на Python или JavaScript. Но глянь, тут всего около двадцати строк, а уже рабочий бот на C. 👉 @Cpportal

Файл на 100 ГБ в Linux, который реально занимает всего 1 МБ на диске. Магия? 🤔 Нет. Это фича под названием sparse files, работающая всего на одном аккуратном вызове системного уровня: lseek (номер 8 на x86_64). Большинство современных файловых систем в Linux умеют sparse файлы (ext4, XFS, Btrfs и так далее), но учти, что, например, FAT/FAT32 такого не поддерживают. На таких ФС системе приходится реально выделять место и писать нули на диск, и тогда экономии нет. lseek() просто двигает файловый оффсет, то есть позицию чтения/записи. Фокус начинается, когда ты делаешь lseek() дальше конца файла и затем что-то записываешь. ФС не выделяет место под этот пустой участок, так называемую дырку. Она просто помнит, что там нули. Реальное место тратится только на те куски, которые ты действительно записал. Вот пример, как создать sparse файл на 10 ГБ, который почти ничего не весит. Обрати внимание на lseek() с прыжком на 10 миллиардов байт вперед, а потом запись всего одного байта.

    
        #include <unistd.h>
#include <fcntl.h>

int main() {
    int fd = open("sparse.file", O_WRONLY | O_CREAT, 0644);
    if (fd == -1) return 1;

    // Seek 10GB forward
    lseek(fd, 10000000000L, SEEK_SET);

    // Write a single byte to mark the new end
    write(fd, "", 1);

    close(fd);
    return 0;
}{}
    

Проверь через ls -lh и du -h. Но как программы находят эти дырки? Читать файл тупо подряд медленно. В современных Linux (начиная с 3.1) lseek прокачали двумя новыми флагами: SEEK_HOLE: находит следующую дырку. SEEK_DATA: находит следующий участок с реальными данными. Это позволяет очень эффективно обрабатывать sparse файлы. И это не просто трюк. Это основа производительности в таких вещах, как: - инструменты бэкапа (пропускают пустые блоки и экономят место) - образы дисков виртуальных машин (qcow2 и подобные) - базы данных (выделяют большие файлы без реального расхода дискового пространства заранее) lseek дает масштабируемость на ровном месте. 👉 @Cpportal

Опенсорсный проект FFmpeg, который используют даже такие компании, как Google, попросил Google профинансировать его волонтёрских разработчиков. FFmpeg сейчас завален багами, которые находят гугловские AI-инструменты для безопасности, а сил быстро всё разгрести у команды просто нет. 👉 @Cpportal