According to Johan van Selst on 3/1/2010 11:02 AM: > Eric Blake wrote: >> Thanks for the report. Can you run the equivalent of strace to see what >> is being attempted when exec'ing the child process? Or maybe this is the >> case of a spurious errno value being left over from some earlier syscall. > > Sure, it's now up on http://mud.stack.nl/~johans/193-ktrace.txt > (output from the test in checks/193.esyscmd)
Actually, it looks like you posted the trace for 007.command_li, given
this line (but no serious loss; it doesn't really matter which esyscmd
gets traced, as long as we can figure out why esyscmd is having problems):
16740 gm4 NAMI "007.command_li"
Any way you can convince ktrace to follow forks? I'm interested in what
stuff happened in 16741, the child process created by vfork, in between
this portion of the parent process:
16740 gm4 CALL vfork
16740 gm4 RET vfork 16741/0x4165
16740 gm4 CALL sigprocmask(SIG_UNBLOCK,0x545a20,0)
16740 gm4 RET sigprocmask 0
16740 gm4 CALL fcntl(0x1,F_GETFL,0x430292)
16740 gm4 RET fcntl 2
16740 gm4 CALL write(0x2,0x7fffffffdb40,0x5)
16740 gm4 GIO fd 2 wrote 5 bytes
"gm4: "
16740 gm4 RET write 5
16740 gm4 CALL write(0x2,0x7fffffffd800,0x18)
16740 gm4 GIO fd 2 wrote 24 bytes
"syscmd subprocess failed"
Or maybe there really is a bug where m4 is using a stale errno from some
previous action. In fact, that may well be the case, since m4 issued an
error message without ever calling wait() on the child process, even
though the trace proves the vfork was succesful. I'll have to look more
closely into the code.
--
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
signature.asc
Description: OpenPGP digital signature
