Re: m4 1.4.14 esyscmd problems on FreeBSD

[Eric Blake]

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             address@hidden

signature.asc
Description: OpenPGP digital signature