On Wed, Oct 24, 2012 at 3:10 PM, Ian Lance Taylor <i...@google.com> wrote: > On Wed, Oct 24, 2012 at 5:31 AM, Uros Bizjak <ubiz...@gmail.com> wrote: >> On Wed, Oct 24, 2012 at 2:18 PM, Andreas Schwab <sch...@linux-m68k.org> >> wrote: >>> Uros Bizjak <ubiz...@gmail.com> writes: >>> >>>> To answer my own question: >>>> >>>> dup(4) = 9 >>>> ... >>>> close(9) = 0 >>>> dup(4) = -1 EBADF (Bad file descriptor) >>>> >>>> Test is calling dup on a closed file descriptor. >>> >>> FD 4 is most likely closed by one of the cloned threads. Use strace -f >>> to follow them. >> >> Yes, indeed! Attached strace -f record confirms this on alpha. >> >> The same happens on x86_64, but for some reason x86_64 doesn't >> complain when executing dup(2) on closed FD. > > The test execs itself by calling the fork and execve functions in > libc. It is the child process that closes the FD after it forks. > From the point of view of the parent process, the FD should still be > open. I don't think you attached the strace -f output so I can't > confirm this.
Eh, sorry, attached now. After the second socketpair and before dup, there is a close in the same thread. Uros.
strace.txt.gz
Description: GNU Zip compressed data
