headers
Gene Spafford | 1 Mar 2010 03:45
Picon
Favicon
Gravatar

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)

Permalink | Reply | 2 comments |
headers
Eric Blake | 1 Mar 2010 18:08
Gravatar

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)

Permalink | Reply | 8 comments |
headers
Johan van Selst | 1 Mar 2010 19:02
Picon
Favicon

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
Permalink | Reply | 7 comments |
headers
Eric Blake | 1 Mar 2010 19:27
Gravatar

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)

Permalink | Reply | 3 comments |
headers
Johan van Selst | 1 Mar 2010 22:55
Picon
Favicon

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)

Permalink | Reply | 2 comments |
headers
Eric Blake | 1 Mar 2010 23:13
Gravatar

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)

Permalink | Reply | 1 comment |
headers
Johan van Selst | 2 Mar 2010 07:18
Picon
Favicon

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
Permalink | Reply | 0 comments |
headers
Bruno Haible | 2 Mar 2010 11:56

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)

Permalink | Reply | 1 comment |
headers
Johan van Selst | 2 Mar 2010 12:38
Picon
Favicon

Re: m4 1.4.14 esyscmd problems on FreeBSD

Hi Bruno,

Bruno Haible wrote:
> FreeBSD's POSIX_SPAWN_SETSIGMASK is 0x20, FreeBSD's POSIX_SPAWN_SETSCHEDULER
> is 0x08. Whereas the gnulib replacement value for POSIX_SPAWN_SETSIGMASK is
> 0x08. It seems gnulib's replacement value is in use when it should not. I'm
> applying this fix.

Thanks for your quick analysis and response. I can confirm that your
patch does the trick for me on all FreeBSD systems where I can my tests.

My thanks to Eric as well. I now have a fully functional m4 1.4.14:
 $ make check
 <skip>
 ====================
 All 103 tests passed
 ====================

Johan
Permalink | Reply | 0 comments |
headers
Translation Project Robot | 2 Mar 2010 17:52

New Finnish PO file for 'm4' (version 1.4o)

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'm4' has been submitted
by the Finnish team of translators.  The file is available at:

    http://translationproject.org/latest/m4/fi.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/m4/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/m4.html

If any question arises, please contact the translation coordinator.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane