Ниже — краткое, но ёмкое объяснение того, что происходит при fork() с точки зрения памяти и общих ресурсов (файловых дескрипторов, буферов), какие варианты вывода возможны и какие гонки/утечки нужно ожидать и избегать.

1) Что делает fork() с памятью

После fork() у родителя и у ребёнка — отдельные адресные пространства. Переменные (stack, heap, global) выглядят одинаково, но физическая память не копируется сразу — применяется copy‑on‑write (COW). То есть страницы остаются общими до тех пор, пока одна сторона не попытается их изменить; при записи страница копируется, модификация остаётся локальной.Изменения переменных в родителе не влияют на ребёнка и наоборот (после первой записи они уже независимы).

2) Файловые дескрипторы и открытое описание файла (open file description)

Дескриптор (int fd) дублируется: и в родителе, и в ребёнке есть свои дескрипторы, но они указывают на одно и то же «open file description» в ядре.Это означает: общий указатель смещения (file offset), общие флаги (например O_APPEND — запись всегда в конец в атомарной манере), и общая запись/блокировка на уровне описания файла (в зависимости от типа блокировки).Следствие: если и родитель, и ребёнок выполняют write(fd,...), смещение будет изменяться общей структурой ядра — последовательность записей зависит от планировщика/порядка системных вызовов, а не от независимых смещений.

3) Поведение stdio (FILE*) и буферизация

Потоки stdio (FILE*, printf и т.п.) хранят внутренние буферы в пользовательском пространстве. При fork буфер LOGICALLY дублируется (копируется) вместе с адресным пространством.Если до fork() в stdout/FILE* что‑то было записано в буфер и не было flushed (fflush / newline при line‑buffered), то после fork обе копии буфера при завершении/flush выдадут один и тот же фрагмент — получится дублированный вывод.Если вывод идёт на терминал, stdout обычно line‑buffered: printf с '\n' сразу сбрасывает буфер, и дублирования не будет. Если вывод в файл/pipe — буфер может не сброситься и данные продублируются.

4) Варианты вывода (типичные примеры)

Пример A:
printf("hello"); fork(); fflush(stdout);
— Если fflush до fork не вызван, то после fork оба процесса будут иметь «hello» в буфере; при выходе/flush получится "hello" дважды.Пример B:
fork();
printf("x=%d\n", x);
— Увидите две строки: одна от родителя, одна от ребёнка; порядок строк не детерминирован (зависит от планировщика).Пример C (low‑level write):
fork();
write(fd, "A", 1);
write(fd, "B", 1);
— Порядок символов в файле зависит от порядка выполнения системных вызовов; смещение обновляется ядром. Для обычных файлов POSIX не гарантирует атомарность больших записей; для pipe/FIFO записи длиной <= PIPE_BUF атомарны.Пример D (O_APPEND):
open(..., O_APPEND);
fork();
write(...);
— Записи будут атомарно дописываться в конец (ядро гарантирует позиционирование при O_APPEND).

5) Гонки и проблемы (что может пойти не так)

Гонки на разделяемых ресурсах:
Конкуренция за file offset: два процесса могут писать одновременно, порядок блоков зависит от планировщика.Interleaving: при множественных небольших write() данные могут оказаться перемешанными (особенно для pipe/FIFO/tty ограничена PIPE_BUF).С stdio: дублирование буфера (double output) или потеря/перемешивание данных, если не вызывать fflush/использовать sync.Гонки в памяти:
Переменные в разных процессах не разделяют память после записи, поэтому гонок данных между процессами на уровне переменных нет; но часто программист ожидает совместного состояния — этого не будет.Блокировки и lock‑семантика:
fcntl‑рекорд‑блоки привязаны к процессу; после fork часто поведение блокировок не интуитивно (наследуются ли — зависит от реализации/семантики POSIX). Надёжно: блоки сложны при fork/exec, нужно осторожно.Безопасность в многопоточных программах:
fork() в многопоточном процессе опасен: в дочернем существует только один поток (тот, что вызвал fork), и нельзя вызывать небезопасные функции, пока не выполнен exec — нужно вызывать только async‑signal‑safe функции.Утечки и зомби‑процессы:
Если родитель не вызывает wait()/waitpid() за ребёнка, ребёнок после завершения станет зомби — утечка записи в таблице процессов до тех пор, пока его не реапнут. Это не утечка памяти в адресном пространстве ребёнка (оно освобождается), но ресурс в таблице процессов остаётся.Дублированные файловые дескрипторы: если ни одна сторона не закрывает fd, он остаётся открыт до выхода процесса; это не «утечка» в смысле бессмертного дескриптора, но может привести к превышению лимитов открытых файлов.Если родитель завершился, дочерний получает init (pid 1) как родителя; это обычно OK.

6) Практические рекомендации

Перед fork: flush всех stdio‑буферов (fflush) если вы не хотите дублирования вывода.Если нужно совместно работать с файлом и координировать смещение/записи — используйте синхронизацию (fcntl locks, posix file locks) или открывайте файл с O_APPEND, или используйте pwrite (передавайте позицию явно).В многопоточных приложениях избегайте fork без exec; используйте posix_spawn или fork+exec последовательность.Всегда wait() за дочерей или установите SIGCHLD обработчик / использовать SIG_IGN по POSIX, чтобы избежать зомби (внимание: SIG_IGN для SIGCHLD ведёт к немедленному reaping унаследованных детей на некоторых системах, но поведение портативно разное).

7) Короткий итог

fork даёт независимые адресные пространства (COW до записи).Файловые дескрипторы указывают на одно и то же открытое описание файла — смещение и некоторые свойства общие.stdio‑буферы дублируются и могут привести к дублирующему выводу, если их не сбрасывать.Возможны гонки на уровне файлового смещения/записей и неожиданные дублирования stdout; возможны зомби‑процессы и «логические утечки» открытых дескрипторов, если не управлять ими.

Если дадите конкретный полный фрагмент кода, опишу точные возможные варианты вывода и где именно возникнут гонки/утечки для этого кода.