Hi! ----
While investigating another issue on Solaris I noticed that ksh93 has regulary this sequence in the "truss" log if I run $ truss -o xxx ~/bin/ksh -c 'true | true' # -- snip -- sigaction(SIGSEGV, 0xFFFFFFFF7FFFE5C0, 0xFFFFFFFF7FFFE6C8) = 0 sigaction(SIGSEGV, 0xFFFFFFFF7FFFE5C0, 0xFFFFFFFF7FFFE6C8) = 0 lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000) = 0xFFBFFEFF [0x0000FFFF] fstat(3, 0xFFFFFFFF7FFFE970) = 0 fstat(3, 0xFFFFFFFF7FFFEA50) = 0 fcntl(3, F_DUPFD, 0x00000000) = 0 close(3) = 0 close(3) Err#9 EBADF close(0) = 0 -- snip -- Erm... my first thought was: Why does it try to close an fd twice ? Taking a closer look with $ truss -u :: ... # shows this: -- snip -- /1...@1: <- ksh:sfsync() = 0 /1...@1: -> libc:fstat(0x3, 0xffffffff7fffea50, 0x0, 0x0) /1: fstat(3, 0xFFFFFFFF7FFFEA50) = 0 /1...@1: <- libc:fstat() = 0 /1...@1: <- ksh:sfsetbuf() = 0x10039f780 /1...@1: <- ksh:sfdisc() = 0x1003893a0 /1...@1: <- ksh:sh_iostream() = 0x100389980 /1...@1: -> ksh:sfsetfd(0x100389980, 0x0, 0x0, 0x0) /1...@1: -> ksh:_sfdup(0x3, 0x0, 0x0, 0x0) /1...@1: -> libc:fcntl(0x3, 0x0, 0x0, 0x0) /1...@1: -> libc:__fcntl(0x3, 0x0, 0x0, 0x0) /1...@1: -> libc:__fcntl_syscall(0x3, 0x0, 0x0, 0x0) /1: fcntl(3, F_DUPFD, 0x00000000) = 0 /1...@1: <- libc:fcntl() = 0 /1...@1: <- ksh:_sfdup() = 0 /1...@1: -> libc:close(0x3, 0x0, 0x0, 0x0) /1...@1: -> libc:_aio_close(0x3, 0x0, 0x0, 0x0) /1...@1: <- libc:_aio_close() = 3 /1...@1: -> libc:__close(0x3, 0x0, 0x0, 0x0) /1: close(3) = 0 /1...@1: <- libc:close() = 0 /1...@1: -> ksh:sftrack(0x100389980, 0xffffffffffffffff, 0x0, 0x0) /1...@1: -> ksh:sh_getinterp(0x0, 0x0, 0x0, 0x0) /1...@1: <- ksh:sh_getinterp() = 0x1003611c0 /1...@1: -> ksh:sfset(0x100389980, 0x0, 0x0, 0x0) /1...@1: <- ksh:sfset() = 17425 /1...@1: <- ksh:sftrack() = 0x100389980 /1...@1: <- ksh:sfsetfd() = 0 /1...@1: -> ksh:sfswap(0x100389980, 0x100364be0, 0x0, 0x0) /1...@1: -> libc_psr:memcpy(0xffffffff7fffecb8, 0x100389980, 0xb0, 0x0) /1...@1: <- libc_psr:memcpy() = 0xffffffff7fffecb8 /1...@1: -> libc_psr:memcpy(0x100389980, 0x100364be0, 0xb0, 0x0) /1...@1: <- libc_psr:memcpy() = 0x100389980 /1...@1: -> libc_psr:memcpy(0x100364be0, 0xffffffff7fffecb8, 0xb0, 0x0) /1...@1: <- libc_psr:memcpy() = 0x100364be0 /1...@1: -> ksh:_ast_free(0x100389980, 0xffffffff7fffed68, 0x0, 0x0) /1...@1: -> ksh:bestfree(0x100365718, 0x100389980, 0x0, 0x0) /1...@1: -> ksh:nomalloc(0x100365718, 0x6, 0x100389980, 0x100365648) /1...@1: <- ksh:nomalloc() = 0 /1...@1: <- ksh:bestfree() = 0 /1...@1: <- ksh:_ast_free() = 0x100389980 /1...@1: <- ksh:sfswap() = 0x100364be0 /1...@1: -> ksh:sfset(0x100364be0, 0x840, 0x1, 0x0) /1...@1: <- ksh:sfset() = 17937 /1...@1: -> ksh:sh_close(0x3, 0x840, 0x1, 0x0) /1...@1: -> ksh:sh_getinterp(0x0, 0x0, 0x0, 0x0) /1...@1: <- ksh:sh_getinterp() = 0x1003611c0 /1...@1: -> libc:close(0x3, 0x0, 0x0, 0x0) /1...@1: -> libc:_aio_close(0x3, 0x0, 0x0, 0x0) /1...@1: <- libc:_aio_close() = 3 /1...@1: -> libc:__close(0x3, 0x0, 0x0, 0x0) /1: close(3) Err#9 EBADF /1...@1: -> libc:_cerror(0x9, 0x0, 0x0, 0x0) /1...@1: -> libc:___errno(0x0, 0x0, 0x0, 0x0) /1...@1: <- libc:___errno() = 0xffffffff7f155440 /1...@1: <- libc:close() = -1 /1...@1: <- ksh:sh_close() = -1 /1...@1: <- ksh:sh_iorenumber() = 0 /1...@1: -> ksh:sfset(0x100364be0, 0x840, 0x0, 0x0) /1...@1: <- ksh:sfset() = 18001 /1...@1: -> libc:setjmp(0xffffffff7ffff0d0, 0x840, 0x0, 0x0) /1...@1: <- libc:setjmp() = 0 /1...@1: -> ksh:sh_redirect(0x1003611c0, 0x0, 0x1, 0x0) /1...@1: <- ksh:sh_redirect() = 1 -- snip -- >From looking at it I think this cannot be right - |sfsetfd()| triggers the first |close()|, followed by an explicit |sh_close()| which calls the 2nd |close()| ... ... David/Glenn... what do you think ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers
