Gene Spafford | 1 Mar 03:45 2010
Picon

Re: [GNU Autoconf 2.65] testsuite: 229 failed

Actually,  I had something like that in place, but found an old (very old) debugging statement that was
putting out a single space.   Once fixed, those problems went away.

I have built or tried to build the following 4 packages on my system:
m4-1.4.14
automake-1.11
autoconf-2.65
ntp-4.2.6p1-RC5 

After the change, m4 makes and passes the self-check.  Thus, we can drop that address going forward. :-)

Automake and autoconf both build, but neither passes all the self-tests.

ntp won't even build because of something in the configuration files.  It appears to be doubly defining some
constants.  As near as I can tell from trying to look at the autoconfig stuff, it thinks that some of the
constants in <sys/int_types.h>, which are included as part of <inttypes.h> are not defined.  So, it
redefines them in a compat.h file, and the compiler gets very, very unhappy about that.

Email to the ntp bugs list was rejected by the moderator who said I should post to the help list.  I did, but no
one has responded.

So, in my quest to get a new ntp up, I find I have to install a bunch of packages I don't understand, and that I
can't get to pass the checks!

At least you have responded to some of my concerns, for that, thank you.

Under separate cover, and not cc-d to the m4 list, I will send the autoconf error log.   If you want to see the
automake errors, or ntp errors, let me know.  I have a bunch of em. :-)

(What is somewhat depressing about this is that 15-25 years ago, I was writing stuff like this and posting
(Continue reading)

Eric Blake | 1 Mar 18:04 2010
Picon

Re: [PATCH] bootstrap accepts --gnulib-srcdir=SRCDIR

[redirecting to m4-patches; replies can drop bug-m4]

According to Giuseppe Scrivano on 2/27/2010 2:48 PM:
> Hi,
> 
> I saw `bootstrap' doesn't accept --gnulib-srcdir as it is already done
> by other projects using gnulib.  It doesn't add a new feature as it can
> be already done specifying GNULIB_SRCDIR, it just make the script more
> similar to scripts used by other projects doing a bootstrap from
> gnulib.
> 
> What do you think?

Looks nice.  I'm queueing it up for branch-1.6 and master; I'm really
hoping to release 1.6 in the next month or two rather than having to
continue to maintain branch-1.4.

> Subject: [PATCH] bootstrap accepts --gnulib-srcdir=SRCDIR
> 
> * bootstrap: When --gnulib-srcdir=SRCDIR is specified, change the value
> of GNULIB_SRCDIR to $SRCDIR.  Document --gnulib-srcdir usage.

--

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

Eric Blake             ebb9 <at> byu.net

_______________________________________________
(Continue reading)

Eric Blake | 1 Mar 18:08 2010
Picon

Re: m4 1.4.14 esyscmd problems on FreeBSD

According to Johan van Selst on 2/28/2010 3:12 PM:
> Greetings,
> 
> I tested the latest m4 on FreeBSD and found that with this installed, I
> cannot compile Apache or PHP programs anymore. The problem seems to be
> with esyscmd changes in the latest release (1.4.13 works fine).
> The typical error message looks something like this (from Apache 2):
> 
>  /usr/local/bin/gm4: esyscmd subprocess failed: Invalid argument
>  /usr/local/bin/gm4:configure.in:398: cannot run command `./build/config-stubs .': Invalid argument

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.

I'll try and get on a FreeBSD machine and see if I can reproduce this.
But my initial pre-release testing on BSD did not fail, so I will have to
figure out what is different between my environment and yours.

> --- m4-tmp.22799/m4-xerr        2010-02-28 23:00:26.000000000 +0100
> +++ m4-tmp.22799/m4-err 2010-02-28 23:00:26.000000000 +0100
>  <at>  <at>  -0,0 +1,2  <at>  <at> 
> +m4: syscmd subprocess failed: Invalid argument
> +m4:stdin:5: cannot run command `POSIXLY_CORRECT=1 'm4' -Dbar=hello foo -Dbar=world foo': Invalid argument

--

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

Eric Blake             ebb9 <at> byu.net

(Continue reading)

Johan van Selst | 1 Mar 19:02 2010
Picon

Re: m4 1.4.14 esyscmd problems on FreeBSD

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)

> I'll try and get on a FreeBSD machine and see if I can reproduce this.
> But my initial pre-release testing on BSD did not fail, so I will have to
> figure out what is different between my environment and yours.

I shall check it on different systems later (tomorrow probably; not
much time now).

Johan
Eric Blake | 1 Mar 19:27 2010
Picon

Re: m4 1.4.14 esyscmd problems on FreeBSD

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)
(Continue reading)

Johan van Selst | 1 Mar 22:55 2010
Picon

Re: m4 1.4.14 esyscmd problems on FreeBSD

Eric Blake wrote:
> According to Johan van Selst on 3/1/2010 11:02 AM:
> > 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

Oops, I was rather hurried when posting this: it was 007.command_li
indeed. There is now a new http://mud.stack.nl/~johans/193-ktrace.txt
and http://mud.stack.nl/~johans/007-ktrace.txt (both with child tracing)
for reference.

This quickly identifies a problem:

  2143 gm4      CALL  sigprocmask(SIG_BLOCK,0x545a20,0)
  2143 gm4      RET   sigprocmask 0
  2143 gm4      CALL  vfork
  2144 gm4      RET   fork 0
  2144 gm4      CALL  sched_setscheduler(0,<invalid=0>,0x800a0e918)
  2144 gm4      RET   sched_setscheduler -1 errno 1 Operation not permitted
  2144 gm4      CALL  exit(0x7f)
  2143 gm4      RET   vfork 2144/0x860
  2143 gm4      CALL  sigprocmask(SIG_UNBLOCK,0x545a20,0)
  2143 gm4      RET   sigprocmask 0

The issue seems to be with the seconds argument of sched_setscheduler()
Quoting the FreeBSD <sched.h> there is no argument defined as 0 -
Ref. http://cvsweb.freebsd.org/src/sys/sys/sched.h

	/* POSIX 1003.1b Process Scheduling */

(Continue reading)

Eric Blake | 1 Mar 23:13 2010
Picon

Re: m4 1.4.14 esyscmd problems on FreeBSD

[adding bug-gnulib]

According to Johan van Selst on 3/1/2010 2:55 PM:
> Eric Blake wrote:
>> According to Johan van Selst on 3/1/2010 11:02 AM:
>>> 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
> 
> Oops, I was rather hurried when posting this: it was 007.command_li
> indeed. There is now a new http://mud.stack.nl/~johans/193-ktrace.txt
> and http://mud.stack.nl/~johans/007-ktrace.txt (both with child tracing)
> for reference.
> 
> This quickly identifies a problem:
> 
>   2143 gm4      CALL  sigprocmask(SIG_BLOCK,0x545a20,0)
>   2143 gm4      RET   sigprocmask 0
>   2143 gm4      CALL  vfork
>   2144 gm4      RET   fork 0
>   2144 gm4      CALL  sched_setscheduler(0,<invalid=0>,0x800a0e918)
>   2144 gm4      RET   sched_setscheduler -1 errno 1 Operation not permitted
>   2144 gm4      CALL  exit(0x7f)
>   2143 gm4      RET   vfork 2144/0x860
>   2143 gm4      CALL  sigprocmask(SIG_UNBLOCK,0x545a20,0)
>   2143 gm4      RET   sigprocmask 0
> 
> The issue seems to be with the seconds argument of sched_setscheduler()
> Quoting the FreeBSD <sched.h> there is no argument defined as 0 -
> Ref. http://cvsweb.freebsd.org/src/sys/sys/sched.h
(Continue reading)

Johan van Selst | 2 Mar 07:18 2010
Picon

Re: m4 1.4.14 esyscmd problems on FreeBSD

Eric Blake wrote:
> Johan, can you find the portion in config.log that shows whether the
> native posix_spawn was deemed acceptable or buggy?

It looks acceptable:

 checking for posix_spawn... yes
 checking whether posix_spawn works... yes
 checking whether posix_spawn is declared without a macro... yes
 checking whether posix_spawnp is declared without a macro... yes

The full m4 configure output and the generated logfile are online at
 http://mud.stack.nl/~johans/m4/configure.txt
 http://mud.stack.nl/~johans/m4/config.log

> It may be possible to work around the failure, by priming the configure
> cache.  For example, if the bug is that your posix_spawnp is broken, but
> gnulib is not properly detecting that brokenness, then you could use
> './configure ac_cv_func_posix_spawnp=no' to force the gnulib replacement
> to be compiled in.

I tried this, but it still results in the same errors,
 ../src/m4: esyscmd subprocess failed: Operation not permitted

Thanks for looking in to this,

Johan
Johan van Selst | 2 Mar 09:12 2010
Picon

Re: m4 1.4.14 esyscmd problems on FreeBSD

Johan van Selst wrote:
> Eric Blake wrote:
> > I'll try and get on a FreeBSD machine and see if I can reproduce this.
> > But my initial pre-release testing on BSD did not fail, so I will have to
> > figure out what is different between my environment and yours.
> I shall check it on different systems later (tomorrow probably; not
> much time now).

Oops, the machine that I previously used for FreeBSD 7.x testing has
been upgraded and is now running 8.x as well. I correct my previous
claim: The code actually works fine on FreeBSD 7.2 machines. It's also
fine on OpenBSD (4.7) and MacOS (Darwin 8.11). So it seems something was
changed / broken in FreeBSD 8.0.

For completeness, I also tested on a FreeBSD 9-CURRENT system and this
shows the same broken behaviour as the FreeBSD 8.0 release.

Johan
Bruno Haible | 2 Mar 11:56 2010

Re: m4 1.4.14 esyscmd problems on FreeBSD

Hi Johan,

Thanks for the added details.

> The code actually works fine on FreeBSD 7.2 machines. It's also
> fine on OpenBSD (4.7) and MacOS (Darwin 8.11). So it seems something was
> changed / broken in FreeBSD 8.0.

FreeBSD 8.0 has its own, new implementation of the posix_spawn* functions,
whereas on the other platforms the gnulib replacement is used.

> > This quickly identifies a problem:
> > 
> >   2143 gm4      CALL  sigprocmask(SIG_BLOCK,0x545a20,0)
> >   2143 gm4      RET   sigprocmask 0
> >   2143 gm4      CALL  vfork
> >   2144 gm4      RET   fork 0
> >   2144 gm4      CALL  sched_setscheduler(0,<invalid=0>,0x800a0e918)
> >   2144 gm4      RET   sched_setscheduler -1 errno 1 Operation not permitted
> >   2144 gm4      CALL  exit(0x7f)
> >   2143 gm4      RET   vfork 2144/0x860
> >   2143 gm4      CALL  sigprocmask(SIG_UNBLOCK,0x545a20,0)
> >   2143 gm4      RET   sigprocmask 0

How come that sched_setscheduler is called? The only use of posix_spawn and
posix_spawnp that is made by m4 1.4.14 (see lib/execute.c and lib/pipe.c) is
with a flags value of POSIX_SPAWN_SETSIGMASK. Whereas in the native FreeBSD
posix_spawn[p] (as well as in the gnulib replacement),  sched_setscheduler
is only called if the flags word contains the POSIX_SPAWN_SETSCHEDULER bit.

(Continue reading)


Gmane