Bug reports for the GNU m4 macro processor

Santiago Vila | 18 Jun 2011 20:05

Picon

Bug#630902: m4: FTBFS: FAIL: test-readlink (fwd)

Hello.

I have just received this from the Debian bug system.

I can't reproduce the failure on Debian "testing" (currently using
linux-image-2.6.38-2-amd64).

I can reproduce it, however, on the same Debian testing system if I
use the kernel currently available on "unstable" (linux-image-2.6.39-2-amd64).

Does this mean this is a kernel bug?

The build log says to report this failure here anyway, hence this report.

---------- Forwarded message ----------
From: Daniel Schepler <dschepler <at> gmail.com>
To: submit <at> bugs.debian.org
Date: Sat, 18 Jun 2011 08:47:10 -0700
Subject: Bug#630902: m4: FTBFS: FAIL: test-readlink

Source: m4
Version: 1.4.16-1
Severity: serious

From my pbuilder build log:

...
/usr/bin/make  check-TESTS
make[6]: Entering directory `/tmp/buildd/m4-1.4.16/tests'
make[7]: Entering directory `/tmp/buildd/m4-1.4.16/tests'

(Continue reading)

Santiago Vila | 19 Jun 2011 00:55

Picon

Re: Bug#630902: m4: FTBFS: FAIL: test-readlink

Hi.

I confirm that m4 builds ok using vanilla 2.6.38.8 from kernel.org,
and it fails using vanilla 2.6.39.1 from kernel.org.

Santiago Vila | 19 Jun 2011 18:24

Picon

Re: Bug#630902: m4: FTBFS: FAIL: test-readlink

For the record, this is what "git bisect" says:

65cfc6722361570bfe255698d9cd4dccaf47570d is the first bad commit

commit 65cfc6722361570bfe255698d9cd4dccaf47570d
Author: Al Viro <viro <at> zeniv.linux.org.uk>
Date:   Sun Mar 13 15:56:26 2011 -0400

    readlinkat(), fchownat() and fstatat() with empty relative pathnames

    For readlinkat() we simply allow empty pathname; it will fail unless
    we have dfd equal to O_PATH-opened symlink, so we are outside of
    POSIX scope here.  For fchownat() and fstatat() we allow AT_EMPTY_PATH;
    let the caller explicitly ask for such behaviour.

    Signed-off-by: Al Viro <viro <at> zeniv.linux.org.uk>

Eric Blake | 20 Jun 2011 19:28

Picon

Bug#630902: m4: FTBFS: FAIL: test-readlink

[adding bug-gnulib]

On 06/18/2011 12:05 PM, Santiago Vila wrote:
> I can't reproduce the failure on Debian "testing" (currently using
> linux-image-2.6.38-2-amd64).
>
> I can reproduce it, however, on the same Debian testing system if I
> use the kernel currently available on "unstable"
(linux-image-2.6.39-2-amd64).
>
> Does this mean this is a kernel bug?

On 06/19/2011 10:24 AM, Santiago Vila wrote:
> For the record, this is what "git bisect" says:
> 
> 65cfc6722361570bfe255698d9cd4dccaf47570d is the first bad commit
> 
> commit 65cfc6722361570bfe255698d9cd4dccaf47570d
> Author: Al Viro <viro <at> zeniv.linux.org.uk>
> Date:   Sun Mar 13 15:56:26 2011 -0400
> 
>     readlinkat(), fchownat() and fstatat() with empty relative pathnames
>     
>     For readlinkat() we simply allow empty pathname; it will fail unless
>     we have dfd equal to O_PATH-opened symlink, so we are outside of
>     POSIX scope here.  For fchownat() and fstatat() we allow AT_EMPTY_PATH;
>     let the caller explicitly ask for such behaviour.
>     
>     Signed-off-by: Al Viro <viro <at> zeniv.linux.org.uk>

(Continue reading)

Santiago Vila | 26 Jul 2011 15:50

Picon

Re: Bug#630902: m4: FTBFS: FAIL: test-readlink

B1;2403;0cOn Mon, 20 Jun 2011, Eric Blake wrote:

> > For the record, this is what "git bisect" says:
> > 
> > 65cfc6722361570bfe255698d9cd4dccaf47570d is the first bad commit
> > 
> > commit 65cfc6722361570bfe255698d9cd4dccaf47570d
> > Author: Al Viro <viro <at> zeniv.linux.org.uk>
> > Date:   Sun Mar 13 15:56:26 2011 -0400
> > 
> >     readlinkat(), fchownat() and fstatat() with empty relative pathnames
> >     
> >     For readlinkat() we simply allow empty pathname; it will fail unless
> >     we have dfd equal to O_PATH-opened symlink, so we are outside of
> >     POSIX scope here.  For fchownat() and fstatat() we allow AT_EMPTY_PATH;
> >     let the caller explicitly ask for such behaviour.
> >     
> >     Signed-off-by: Al Viro <viro <at> zeniv.linux.org.uk>
> 
> Yes, most likely this is a kernel and/or glibc bug.  POSIX requires
> readlinkat(dfd, "", buf, size) to fail with ENOENT, if dfd is either
> AT_FDCWD or open on a directory.  Which does strace say about the
> syscall made just before the gnulib test-readlink fails?

Sorry for the late reply. I'm including the complete strace at the end.

> I'll try and reproduce this setup myself, [...]

Please do so. Apparently this is an issue with just Linux and m4, and
does not seem to be specifical to Debian at all, so it should be easy

(Continue reading)

Eric Blake | 26 Jul 2011 16:07

Picon

Re: Bug#630902: m4: FTBFS: FAIL: test-readlink

On 07/26/2011 07:50 AM, Santiago Vila wrote:
>> Yes, most likely this is a kernel and/or glibc bug.  POSIX requires
>> readlinkat(dfd, "", buf, size) to fail with ENOENT, if dfd is either
>> AT_FDCWD or open on a directory.  Which does strace say about the
>> syscall made just before the gnulib test-readlink fails?
>

> --- SIGCHLD (Child exited)  <at>  0 (0) ---
> readlink("no_such", 0x7fff370e7340, 80) = -1 ENOENT (No such file or directory)
> readlink("no_such/", 0x7fff370e7340, 80) = -1 ENOENT (No such file or directory)
> readlink("", 0x7fff370e7340, 80)        = -1 EINVAL (Invalid argument)

There's the bug.  This is failing with EINVAL instead of ENOENT, which 
is contrary to POSIX.  However, this kernel bug has already been papered 
over in gnulib, which means that it is merely a matter of updating m4 to 
use newer gnulib to make this test failure go away.

http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=dc446909

--

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Santiago Vila | 29 Jul 2011 12:54

Picon

Re: Bug#630902: m4: FTBFS: FAIL: test-readlink

On Tue, 26 Jul 2011, Eric Blake wrote:

> On 07/26/2011 07:50 AM, Santiago Vila wrote:
> > --- SIGCHLD (Child exited)  <at>  0 (0) ---
> > readlink("no_such", 0x7fff370e7340, 80) = -1 ENOENT (No such file or
> > directory)
> > readlink("no_such/", 0x7fff370e7340, 80) = -1 ENOENT (No such file or
> > directory)
> > readlink("", 0x7fff370e7340, 80)        = -1 EINVAL (Invalid argument)
> 
> There's the bug.  This is failing with EINVAL instead of ENOENT, which is
> contrary to POSIX.  However, this kernel bug has already been papered over in
> gnulib, which means that it is merely a matter of updating m4 to use newer
> gnulib to make this test failure go away.
> 
> http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=dc446909

Thanks a lot! I patched the Debian package for m4 accordingly and the
problem is now gone.

Eric Blake | 26 Jul 2011 16:07

Picon

Bug#630902: m4: FTBFS: FAIL: test-readlink

On 07/26/2011 07:50 AM, Santiago Vila wrote:
>> Yes, most likely this is a kernel and/or glibc bug.  POSIX requires
>> readlinkat(dfd, "", buf, size) to fail with ENOENT, if dfd is either
>> AT_FDCWD or open on a directory.  Which does strace say about the
>> syscall made just before the gnulib test-readlink fails?
>

> --- SIGCHLD (Child exited)  <at>  0 (0) ---
> readlink("no_such", 0x7fff370e7340, 80) = -1 ENOENT (No such file or directory)
> readlink("no_such/", 0x7fff370e7340, 80) = -1 ENOENT (No such file or directory)
> readlink("", 0x7fff370e7340, 80)        = -1 EINVAL (Invalid argument)

There's the bug.  This is failing with EINVAL instead of ENOENT, which 
is contrary to POSIX.  However, this kernel bug has already been papered 
over in gnulib, which means that it is merely a matter of updating m4 to 
use newer gnulib to make this test failure go away.

http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=dc446909

--

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Eric Blake | 26 Jul 2011 16:07

Picon

Bug#630902: m4: FTBFS: FAIL: test-readlink

On 07/26/2011 07:50 AM, Santiago Vila wrote:
>> Yes, most likely this is a kernel and/or glibc bug.  POSIX requires
>> readlinkat(dfd, "", buf, size) to fail with ENOENT, if dfd is either
>> AT_FDCWD or open on a directory.  Which does strace say about the
>> syscall made just before the gnulib test-readlink fails?
>

> --- SIGCHLD (Child exited)  <at>  0 (0) ---
> readlink("no_such", 0x7fff370e7340, 80) = -1 ENOENT (No such file or directory)
> readlink("no_such/", 0x7fff370e7340, 80) = -1 ENOENT (No such file or directory)
> readlink("", 0x7fff370e7340, 80)        = -1 EINVAL (Invalid argument)

There's the bug.  This is failing with EINVAL instead of ENOENT, which 
is contrary to POSIX.  However, this kernel bug has already been papered 
over in gnulib, which means that it is merely a matter of updating m4 to 
use newer gnulib to make this test failure go away.

http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=dc446909

--

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Santiago Vila | 26 Jul 2011 15:50

Picon

Bug#630902: m4: FTBFS: FAIL: test-readlink

B1;2403;0cOn Mon, 20 Jun 2011, Eric Blake wrote:

> > For the record, this is what "git bisect" says:
> > 
> > 65cfc6722361570bfe255698d9cd4dccaf47570d is the first bad commit
> > 
> > commit 65cfc6722361570bfe255698d9cd4dccaf47570d
> > Author: Al Viro <viro <at> zeniv.linux.org.uk>
> > Date:   Sun Mar 13 15:56:26 2011 -0400
> > 
> >     readlinkat(), fchownat() and fstatat() with empty relative pathnames
> >     
> >     For readlinkat() we simply allow empty pathname; it will fail unless
> >     we have dfd equal to O_PATH-opened symlink, so we are outside of
> >     POSIX scope here.  For fchownat() and fstatat() we allow AT_EMPTY_PATH;
> >     let the caller explicitly ask for such behaviour.
> >     
> >     Signed-off-by: Al Viro <viro <at> zeniv.linux.org.uk>
> 
> Yes, most likely this is a kernel and/or glibc bug.  POSIX requires
> readlinkat(dfd, "", buf, size) to fail with ENOENT, if dfd is either
> AT_FDCWD or open on a directory.  Which does strace say about the
> syscall made just before the gnulib test-readlink fails?

Sorry for the late reply. I'm including the complete strace at the end.

> I'll try and reproduce this setup myself, [...]

Please do so. Apparently this is an issue with just Linux and m4, and
does not seem to be specifical to Debian at all, so it should be easy

(Continue reading)

Santiago Vila | 26 Jul 2011 15:50

Picon

Bug#630902: m4: FTBFS: FAIL: test-readlink

B1;2403;0cOn Mon, 20 Jun 2011, Eric Blake wrote:

> > For the record, this is what "git bisect" says:
> > 
> > 65cfc6722361570bfe255698d9cd4dccaf47570d is the first bad commit
> > 
> > commit 65cfc6722361570bfe255698d9cd4dccaf47570d
> > Author: Al Viro <viro <at> zeniv.linux.org.uk>
> > Date:   Sun Mar 13 15:56:26 2011 -0400
> > 
> >     readlinkat(), fchownat() and fstatat() with empty relative pathnames
> >     
> >     For readlinkat() we simply allow empty pathname; it will fail unless
> >     we have dfd equal to O_PATH-opened symlink, so we are outside of
> >     POSIX scope here.  For fchownat() and fstatat() we allow AT_EMPTY_PATH;
> >     let the caller explicitly ask for such behaviour.
> >     
> >     Signed-off-by: Al Viro <viro <at> zeniv.linux.org.uk>
> 
> Yes, most likely this is a kernel and/or glibc bug.  POSIX requires
> readlinkat(dfd, "", buf, size) to fail with ENOENT, if dfd is either
> AT_FDCWD or open on a directory.  Which does strace say about the
> syscall made just before the gnulib test-readlink fails?

Sorry for the late reply. I'm including the complete strace at the end.

> I'll try and reproduce this setup myself, [...]

Please do so. Apparently this is an issue with just Linux and m4, and
does not seem to be specifical to Debian at all, so it should be easy

(Continue reading)

Eric Blake | 20 Jun 2011 19:28

Picon

Bug#630902: m4: FTBFS: FAIL: test-readlink

[adding bug-gnulib]

On 06/18/2011 12:05 PM, Santiago Vila wrote:
> I can't reproduce the failure on Debian "testing" (currently using
> linux-image-2.6.38-2-amd64).
>
> I can reproduce it, however, on the same Debian testing system if I
> use the kernel currently available on "unstable"
(linux-image-2.6.39-2-amd64).
>
> Does this mean this is a kernel bug?

On 06/19/2011 10:24 AM, Santiago Vila wrote:
> For the record, this is what "git bisect" says:
> 
> 65cfc6722361570bfe255698d9cd4dccaf47570d is the first bad commit
> 
> commit 65cfc6722361570bfe255698d9cd4dccaf47570d
> Author: Al Viro <viro <at> zeniv.linux.org.uk>
> Date:   Sun Mar 13 15:56:26 2011 -0400
> 
>     readlinkat(), fchownat() and fstatat() with empty relative pathnames
>     
>     For readlinkat() we simply allow empty pathname; it will fail unless
>     we have dfd equal to O_PATH-opened symlink, so we are outside of
>     POSIX scope here.  For fchownat() and fstatat() we allow AT_EMPTY_PATH;
>     let the caller explicitly ask for such behaviour.
>     
>     Signed-off-by: Al Viro <viro <at> zeniv.linux.org.uk>

(Continue reading)

Santiago Vila | 19 Jun 2011 18:24

Picon

Bug#630902: m4: FTBFS: FAIL: test-readlink

For the record, this is what "git bisect" says:

65cfc6722361570bfe255698d9cd4dccaf47570d is the first bad commit

commit 65cfc6722361570bfe255698d9cd4dccaf47570d
Author: Al Viro <viro <at> zeniv.linux.org.uk>
Date:   Sun Mar 13 15:56:26 2011 -0400

    readlinkat(), fchownat() and fstatat() with empty relative pathnames

    For readlinkat() we simply allow empty pathname; it will fail unless
    we have dfd equal to O_PATH-opened symlink, so we are outside of
    POSIX scope here.  For fchownat() and fstatat() we allow AT_EMPTY_PATH;
    let the caller explicitly ask for such behaviour.

    Signed-off-by: Al Viro <viro <at> zeniv.linux.org.uk>

Santiago Vila | 19 Jun 2011 18:24

Picon

Bug#630902: m4: FTBFS: FAIL: test-readlink

For the record, this is what "git bisect" says:

65cfc6722361570bfe255698d9cd4dccaf47570d is the first bad commit

commit 65cfc6722361570bfe255698d9cd4dccaf47570d
Author: Al Viro <viro <at> zeniv.linux.org.uk>
Date:   Sun Mar 13 15:56:26 2011 -0400

    readlinkat(), fchownat() and fstatat() with empty relative pathnames

    For readlinkat() we simply allow empty pathname; it will fail unless
    we have dfd equal to O_PATH-opened symlink, so we are outside of
    POSIX scope here.  For fchownat() and fstatat() we allow AT_EMPTY_PATH;
    let the caller explicitly ask for such behaviour.

    Signed-off-by: Al Viro <viro <at> zeniv.linux.org.uk>

Santiago Vila | 19 Jun 2011 00:55

Picon

Bug#630902: m4: FTBFS: FAIL: test-readlink

Hi.

I confirm that m4 builds ok using vanilla 2.6.38.8 from kernel.org,
and it fails using vanilla 2.6.39.1 from kernel.org.

Santiago Vila | 19 Jun 2011 00:55

Picon

Bug#630902: m4: FTBFS: FAIL: test-readlink

Hi.

I confirm that m4 builds ok using vanilla 2.6.38.8 from kernel.org,
and it fails using vanilla 2.6.39.1 from kernel.org.

Return

Return to gmane.comp.gnu.m4.bugs.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane