Re: bash closes fd twice.

[John McKown]

On Fri, Dec 11, 2015 at 2:40 AM, Yoriyuki Yamagata <yoriyuki.yamagata@aist.go.jp> wrote:

Dear list,

I found that bash tries to close the same fd twice, consecutively.  I’m using Mac OS X Yosemite, and bash is the newest available (bash-master from http://tiswww.case.edu/php/chet/bash/bashtop.html yesterday).

To reproduce the phenomenon, just run this shell script.

— begin ---
#!/Users/XXXX/bin/bash

set -- `cat "testfile" | sed '/^\#/d’`
— end ---
Name it testscript

testfile is the empty file.

Then, run druss

$ sudo dtruss -fa sudo -u XXXX ./testscript

The part of output:

96765/0x20858e:    173615  173171 173168 fork()          = 96766 0
96766/0x208590:        74:        0:       0 fork()              = 0 0
96766/0x208590:        75       5      0 thread_selfid(0x0, 0x0, 0x0)            = 2131344 0
96766/0x208590:        77       3      0 bsdthread_register(0x7FFF95D0E3E0, 0x7FFF95D0E3D0, 0x2000)              = -1 Err#22
96765/0x20858e:    173714       4      0 sigprocmask(0x3, 0x7FFF59BFD7A0, 0x0)           = 0x0 0
96765/0x20858e:    173717       3      1 close(0x4)              = 0 0
96765/0x20858e:    173739       1      0 close(0x4)              = -1 Err#9

I do not know it is an important problem, but closing the same file descriptor twice could be fishy.

Or maybe I missed something?

Best,
 —
Yoriyuki Yamagata
National Institute of Advanced Science and Technology (AIST), Senior Researcher

​The same happens on Fedora Linux 22.

Linux it-johnmckown-linux 4.2.6-201.fc22.x86_64 #1 SMP Tue Nov 24 18:42:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

bash --version

GNU bash, version 4.3.42(1)-release (x86_64-redhat-linux-gnu)

Copyright (C) 2013 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"

<trace output>

...

pipe([3, 4])                            = 0

rt_sigprocmask(SIG_BLOCK, [INT CHLD], [CHLD], 8) = 0

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f31c859a9d0) = 17257

rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0

close(4)                                = 0

close(4)                                = -1 EBADF (Bad file descriptor)

rt_sigprocmask(SIG_BLOCK, [INT CHLD], [CHLD], 8) = 0

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f31c859a9d0) = 17258

rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0

close(3)                                = 0

rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0

rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0

rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0

rt_sigaction(SIGINT, {0x556792b10290, [], SA_RESTORER, 0x7f31c7c26a50}, {0x556792b2acb0, [], SA_RESTORER, 0x7f31c7c26a50}, 8) = 0

wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 17257

wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 17258

rt_sigaction(SIGINT, {0x556792b2acb0, [], SA_RESTORER, 0x7f31c7c26a50}, {0x556792b10290, [], SA_RESTORER, 0x7f31c7c26a50}, 8) = 0

rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0

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

rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0

--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=17257, si_uid=1009, si_status=0, si_utime=0, si_stime=0} ---

wait4(-1, 0x7ffd3e7b4790, WNOHANG, NULL) = -1 ECHILD (No child processes)

rt_sigreturn({mask=[]})                 = 0

exit_group(0)                           = ?

+++ exited with 0 +++

</trace>​

 

--

Schrodinger's backup: The condition of any backup is unknown until a restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown