execve로 새 프로그램을 실행할 때 argv와 envp는 누가 만들며 기존 heap·stack·signal handler는 어떻게 되나요?

execve를 호출하는 launcher가 argv와 envp 포인터 배열 및 문자열을 준비해 새 image에 전달합니다. 성공한 exec는 child를 만드는 fork가 아니라 현재 process의 code·data·heap·stack을 새 executable image로 바꾸는 동작이므로 PID는 유지됩니다. launcher가 malloc한 설정 객체나 stack frame, 기존 함수 주소가 worker의 heap과 code로 이어지는 것은 아닙니다. 예를 들어 argv=[worker,--port,8080], envp=[PATH=/usr/bin,CONFIG=/etc/app]라면 worker는 시작 규약으로 이 문자열을 읽지만 old heap 객체는 읽지 못합니다.

signal도 구분해야 합니다. caught handler는 새 image에 같은 함수 주소가 없으므로 default로 reset되고, Linux에서는 ignored disposition이 유지됩니다. calling thread의 mask와 pending signal은 POSIX exec 규칙에 따라 새 initial thread에 상속되며 alternate stack은 별도 폐기 규칙을 따릅니다. exec가 실패하면 기존 image와 PID·heap·thread가 남아 있으므로 errno, 임시 env 배열, 열린 자원의 정리는 실패 경로에서 수행해야 합니다. 환경 변수는 process memory의 문자열일 뿐이므로 token을 자동으로 안전하게 전달하는 비밀 저장소로 취급하지 않습니다.

argv와 envp의 문자열 수명도 호출자 계약에 포함됩니다. exec 성공 뒤에는 새 image의 초기화 코드가 전달된 배열을 읽지만, launcher의 이후 stack frame을 참조하는 식으로 설계할 수 없습니다. 환경 key를 추가하면 하위 library의 동작이 바뀔 수 있으므로 allowlist와 함께 기본값·충돌 우선순위도 기록합니다. 반대로 경로가 존재하지 않아 exec가 실패하면 launcher는 같은 주소 공간에서 계속 실행하므로, 실패 로그가 old handler와 old heap을 전제로 작성되어야 합니다.