Where Guile opens a file in order to read code from it, that file descriptor ought to be private to Guile, in the sense that it should not be passed on to another program across exec. But it is so leaked, as can be seen especially clearly using Linux's /proc/*/fd feature:
$ cat /tmp/t0 (system (string-append "ls -l /proc/" (number->string (getpid)) "/fd; ls -l /proc/self/fd")) $ guile-2.2.6 --no-auto-compile -s /tmp/t0 total 0 lrwx------ 1 zefram zefram 64 Nov 27 05:21 0 -> /dev/pts/4 lrwx------ 1 zefram zefram 64 Nov 27 05:21 1 -> /dev/pts/4 lrwx------ 1 zefram zefram 64 Nov 27 05:21 2 -> /dev/pts/4 lr-x------ 1 zefram zefram 64 Nov 27 05:21 3 -> pipe:[59357425] l-wx------ 1 zefram zefram 64 Nov 27 05:21 4 -> pipe:[59357425] lr-x------ 1 zefram zefram 64 Nov 27 05:21 5 -> pipe:[59357426] l-wx------ 1 zefram zefram 64 Nov 27 05:21 6 -> pipe:[59357426] lr-x------ 1 zefram zefram 64 Nov 27 05:21 7 -> /tmp/t0 total 0 lrwx------ 1 zefram zefram 64 Nov 27 05:21 0 -> /dev/pts/4 lrwx------ 1 zefram zefram 64 Nov 27 05:21 1 -> /dev/pts/4 lrwx------ 1 zefram zefram 64 Nov 27 05:21 2 -> /dev/pts/4 lr-x------ 1 zefram zefram 64 Nov 27 05:21 3 -> /proc/3649/fd lr-x------ 1 zefram zefram 64 Nov 27 05:21 7 -> /tmp/t0 $ Observe that the Guile process has open both the script file and a couple of pipes. The ls process also has a file descriptor on the script file, though it does not have the pipes open. Clearly Guile has leaked the script fd, but has avoided leaking the pipe fds. The script fd ought to have the FD_CLOEXEC flag set. Preferably, that flag should be set immediately upon opening the file, by means of the O_CLOEXEC flag. I note that pipes opened by the thread system are already opened with O_CLOEXEC. Guile 2.0 behaves the same as 2.2 in this respect. Guile 1.8 leaks both the script fd and the pipe fds. Guile 1.6 doesn't open any pipes in this test, and also leaks the script fd. -zefram