2016-07-14 28 views
0

bashプロンプトに戻らないプログラムをデバッグしようとしましたが、straceを使用してPIDを与えました。プログラムはバイナリファイルであり、私はソースコードを持っていません。 straceによれば、-1 EBADF (Bad file descriptor)がある。しかし、どのファイルに問題があるのか​​わかりません。straceが不正なファイル記述子を報告しました

strace出口から見ると、lsof -p <PID>の結果はありません。

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 
[[email protected] ~]# lsof -p 29588 
[[email protected] ~]# 

見つからない/誤ったファイルを検索するにはどうすればよいですか?

+1

これは必ずしもバグではありません。 FDが閉じていることを確認したい場合は、最初に開いていることを確認する良い理由はありません。EBADFを閉じると、EBADFを無視して無視してください。 –

+0

...例えば、サブプロセスを開始するときにPythonの 'close_fds'フラグを使用している場合は、FD番号3-255を実行し、開いているかどうかに関わらず、すべてを閉じようとします。 –

+0

ところで、straceの代わりにsysdigを使うことを検討してください。とりわけ、過去に存在していたプロセスのFDテーブル(任意のプロセス、それはシステム全体の監視)をダンプするように求めることができます。時間*。 –

答えて

4

あなたは二度同じファイルディスクリプタをクローズしている:ファイルディスクリプタ番号がファイルにマッピングされていないとき

close(5)        = 0 
close(5)        = -1 EBADF (Bad file descriptor) 
3

EBADFが起こります。したがって、定義上、そこにはであり、問​​題のあるファイルはありません。


これはバグではなく、確かにあなたが探しているバグではありません。たとえファイルが開かれているかわからなくても、FDを閉じようとするのはまったく共通の動作です。ファイルディスクリプタがまだ他の手段で開かれているかどうかをチェックして閉じようとするよりも効率的です条件付きで

+0

* FD5は、以前は '10.10.10.251'に接続されたソケットにマップされていました。*どのように結論づけましたか? –

+0

これは誤読で、率直に言ってFDであった。9.それを引っ込める。 –

1

プログラムをマルチスレッド化した場合、ファイルディスクリプタを複数回閉じると、初めてスレッドを閉じると、別のスレッドがopen()を呼び出して同じファイル記述子を与えることができます別のファイルを参照)。その時点でスレッド内でもう一度closeを呼び出すと、他のスレッドのファイルが閉じられます。常に次のようなものを使用してください:

close(x); x = -1;

再利用されたディスクリプタを誤って閉じないようにしてください。

関連する問題