strace reports bad file descriptor - linux

Question

Trying to debug my program which doesn't return to the bash prompt, I used strace and gave it the PID. The program is a binary file and I don't have the source code. According to the strace, there is a -1 EBADF (Bad file descriptor). However, I don't know which file is problematic.
As you can see below the strace exits, so running lsof -p <PID> has no result.
read(5, "80\0\0\0\00078", 8) = 8
read(5, "prf-exit\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 80) = 80
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2af316b0f000
write(1, "\n", 1) = 1
read(5, "\0\0\0\0", 4) = 4
write(5, "\0\0\0\0", 4) = 4
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 9
setsockopt(9, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(9, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(9, SOL_SOCKET, SO_SNDBUF, [65536], 4) = 0
setsockopt(9, SOL_SOCKET, SO_RCVBUF, [65536], 4) = 0
fcntl(9, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(9, F_SETFL, O_RDWR) = 0
connect(9, {sa_family=AF_INET, sin_port=htons(45323), sin_addr=inet_addr("10.10.10.251")}, 16) = 0
write(9, "12345\0", 6) = 6
write(9, "15 NORMAL_EXITING\0", 19) = 19
read(9, "\0", 1) = 1
close(9) = 0
futex(0x2af31686d9d0, FUTEX_WAIT, 29590, NULL) = 0
futex(0x2af31666c9d0, FUTEX_WAIT, 29589, NULL) = 0
close(6) = 0
close(7) = 0
read(5, "\0\0\0\0", 4) = 4
write(5, "\0\0\0\0", 4) = 4
read(5, "\0\0\0\0", 4) = 4
write(5, "\0\0\0\0", 4) = 4
close(5) = 0
close(5) = -1 EBADF (Bad file descriptor)
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(49986), sin_addr=inet_addr("172.20.54.10")}, 16) = 0
setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(5, SOL_TCP, TCP_NODELAY, [1], 4) = 0
write(5, "\35\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
close(5) = 0
close(4) = 0
exit_group(0) = ?
Process 29588 detached
[root#compute-0-3 ~]# lsof -p 29588
[root#compute-0-3 ~]#
How can I search for the missing/erroneous file?

Answer 1

You're closing the same file descriptor twice:
close(5) = 0
close(5) = -1 EBADF (Bad file descriptor)

Answer 2

EBADF happens when a file descriptor number isn't mapped to a file. Thus, by definition, there is no file that's problematic.
Frankly, this isn't a bug, and certainly isn't the bug you're looking for. It's entirely common behavior to try to close FDs even if you're not sure they were open to begin with -- it's more efficient to do so than to try to check for whether a file descriptor is still open via other means and close it only conditionally.

Answer 3

Closing a file descriptor more than once is a very bad idea if your program is multi-threaded, because after you close it for the first time, another thread can call open() and be given the same file descriptor (but referring to a different file); at which point calling close for a second time in your thread will close the other thread's file. Always use something like:
close(x);
x = -1;
to make sure you don't inadvertently close a reused descriptor.