Bash file descriptor leak

Question

I get a file descriptor leak when I run the following code:

function get_fd_count() { local fds cd /proc/$$/fd; fds=( * ) # avoid a StackOverflow source colorizer bug echo "${#fds[@]}" } function fd_leak_func() { while : ; do echo ">> Current FDs: $(get_fd_count)" read retval new_state < <(set +e; new_state=$(echo foo); retval=$?; printf "%d %s\n" $retval $new_state) done } fd_leak_func 

Tested on 3.2.25 and 4.0.28.

This only happens when the loop is executed inside the function; every time we return to the top-level context, additional file descriptors are closed.

Is this the intended behavior? Are workarounds available?

---

Follow-up report: after posting to the bash -bug mailing list, this was confirmed as an error. Chet indicated that the fix would be included in the next release (as of 4/17/2010).

Answer 1

Here is a simplified example:

 $ fd_leaker() { while :; do read a < <(pwd); c=(/proc/$$/fd/*); c=${#c[@]}; echo $c; done; } $ fd_leaker 

This is not fixed with /bin/true , but mostly fixed with (exit 0) But I get the error "bash: echo: write error: Interrupted system call" using this fix or if I use /bin/pwd instead of the built-in pwd .

It also looks like read . I tried grep . < <(pwd) > /dev/null grep . < <(pwd) > /dev/null and it worked correctly. When I tried while read a; do :; done < <( pwd) while read a; do :; done < <( pwd)

Additional file descriptors in the form:

 lr-x------ 1 user user 64 2010-04-15 19:26 39 -> pipe:[8357879] 

I really do not think that their unbridled creation is intended, because nothing recursive happens there. I really don't see how adding something to the loop should fix it.

Answer 2

Entering /bin/true at the end of the loop corrects it, but I don’t know why and how, or why this happens in the first place.

Answer 3

It seems to be fixed in bash -4.2. I tested with bash -4.2.28 in particular