Re: AIX sysval failure

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Gary V. Vaughan on 2/25/2009 11:10 PM:
> 
> % xlc -o foo foo.c
> % ./foo false
> 0100 0
> 0100 0
> % ./foo
> ffffffff 0
> 90009 0

There we have it.  system() returned -1, rather than the exit value of the
child process, even though the child successfully executed.

> % truss -u:libc.a::system,fork,wait,waitpid,execlp,printf -f ./foo
> 
> Output Format: <pid>: {<childpid>:} <syscall>(<args>...) = <return value>
> 
> 1118340: execve("./foo", 0x2FF22B70, 0x2000EB28)                 argc: 1
> 1118340: 1716323: _sigaction(2, 0x2FF22A60, 0x2FF22A70) = 0
> 1118340: 1716323: _sigaction(3, 0x2FF22A60, 0x2FF22A80) = 0
> 1118340: 1716323: sigprocmask(0, 0x2FF22A64, 0x2FF22A58)        = 0
> 1118340: 1716323: _sigaction(20, 0x2FF22A60, 0x2FF22A90)        = 0
> 1118340: 1716323: kfork()                               = 585844
> 585844: kfork()         (returning as child ...)        = 0

system() calls fork under the hood (expected)...

> 585844: _sigaction(2, 0x2FF22A70, 0x00000000)           = 0
> 585844: _sigaction(3, 0x2FF22A80, 0x00000000)           = 0
> 585844: _sigaction(20, 0x2FF22A90, 0x00000000)          = 0
> 585844: sigprocmask(2, 0x2FF22A58, 0x00000000)          = 0
> 585844: privcheck(910)                                  = 1
> 585844: execve("/usr/bin/sh", 0xF0315F28, 0x2FF22B9C)    argc: 3
> ... shell startup calls ...
> 585844: kioctl(2, 21522, 0x2FF22A08, 0x00000000)        Err#1  EPERM
> 585844: statx("/opt/build/m4-1.4.12.27-ccc137", 0x2FF22790, 176, 020) = 0
> 585844: statx(".", 0x2FF22840, 176, 020)                = 0
> 585844: _getpid()                                       = 585844
> 585844: _getppid()                                      = 1118340
> 585844: kill(585844, 9)                                 = 0

and the child shell properly commits suicide...

> 585844: *** process killed ***
> 1118340: 1716323: kwaitpid(0x2FF22A50, 585844, 4, 0x00000000,
> 0x00000000) = 585844

at which point the parent reaps its status...

> 1118340: 1716323: _sigaction(2, 0x2FF22A70, 0x00000000) = 0
> 1118340: 1716323: _sigaction(3, 0x2FF22A80, 0x00000000) = 0
> 1118340: 1716323: _sigaction(20, 0x2FF22A90, 0x00000000)        = 0
> 1118340: 1716323: sigprocmask(2, 0x2FF22A58, 0x00000000)        = 0
> 1118340: 1716323: ->libc.a:printf(0x10000564, 0xffffffffffffffff, 0x0,
> 0xd0b2, 0x0, 0x267, 0x0, 0x0)
> 1118340: 1716323: kioctl(1, 22528, 0x00000000, 0x00000000) = 0
> ffffffff 0

but somewhere along the way, the status states -1.  I don't see a line
with ->libc.a:system, so I'm not quite sure what the system() return value
was.  But I'm guessing that this particular system() implementation
recognizes that the child died by signal, and treats it as a failure
rather than returning the child's signal exit status.  After all, system()
is allowed to fail.  But this argues that m4 should detect system()
failure and output a warning that includes errno (similar to how it prints
a message "cannot open pipe to command ..." on popen() failure for esyscmd).

> 1118340: 1716323: kwrite(1, " f f f f f f f f   0\n", 11) = 11
> 1118340: 1716323: <-libc.a:printf() = b         0.000000
> 1118340: 1716323: ->libc.a:fork()
> 1118340: 1716323: kfork()                               = 585846
> 585846: kfork()         (returning as child ...)        = 0

Manually forking...

> 585846: kill(585846, 9)                                 = 0
> 585846: *** process killed ***

and we can kill the child...

> 1118340: 1716323: kwaitpid(0x2FF22AF0, -1, 4, 0x00000000, 0x00000000) = 585846
> 1118340: 1716323: <-libc.a:wait() = 8f076               0.000000
> 1118340: 1716323: ->libc.a:printf(0x10000564, 0x90009, 0x0, 0xd0b2,
> 0x0, 0x2ac, 0x0, 0x0)
> 90009 0

and saw the expected status.

> 
> There's definitely something odd going on, but I haven't found the magic
> truss command to reveal it yet :(  If we can either fix the problem by
> using gnulib execute, or fix gnulib execute to work around the problem then
> using it is certainly a very good idea!

I'll experiment with importing the execute module.  In the past, Bruno has
raised other valid points about why we should use it instead of system(),
including the fact that system()'s signal handling is not always ideal.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmmlGcACgkQ84KuGfSFAYBO1QCgjJbzbUU+e09EGpK7g7RX0Nlj
UkgAoNPt+5SAK3e88oo0gRCfpZ548o+E
=cfzS
-----END PGP SIGNATURE-----