GNU bug report logs - #63533
test-mbrlen5.sh failure

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63533 in the body.
You can then email your comments to 63533 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Caleb Zulawski <caleb.zulawski <at> gmail.com>
To: bug-grep <at> gnu.org
Subject: test-mbrlen5.sh failure
Date: Mon, 15 May 2023 20:08:07 -0400

[Message part 1 (text/plain, inline)]

Hi,

I maintain the conda-forge grep package and I'm seeing this build failure
on all Linux targets with the recent 3.11 release:

FAIL: test-mbrlen5.sh
=====================

test-mbrlen.c:47: assertion 'ret == (size_t)(-2)' failed
./test-mbrlen5.sh: line 5: 29982 Aborted (core dumped) LC_ALL=C ${CHECKER}
./test-mbrlen${EXEEXT} 5
FAIL test-mbrlen5.sh (exit status: 1)

[Message part 2 (text/html, inline)]

Message #8 received at 63533 <at> debbugs.gnu.org (full text, mbox):

From: Carlo Arenas <carenas <at> gmail.com>
To: Caleb Zulawski <caleb.zulawski <at> gmail.com>
Cc: 63533 <at> debbugs.gnu.org
Subject: Re: bug#63533: test-mbrlen5.sh failure
Date: Mon, 15 May 2023 23:55:22 -0700

That is a test for a bug that your system image has but that is not
relevant to grep (mbrlen doesn't correctly handle a call with a len of
0).

Carlo

Message #11 received at 63533 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Carlo Arenas <carenas <at> gmail.com>
Cc: Caleb Zulawski <caleb.zulawski <at> gmail.com>, 63533 <at> debbugs.gnu.org
Subject: Re: bug#63533: test-mbrlen5.sh failure
Date: Wed, 17 May 2023 09:53:07 +0200

tags 63533 notabug
close 63533
done

On Tue, May 16, 2023 at 1:34 PM Carlo Arenas <carenas <at> gmail.com> wrote:
> That is a test for a bug that your system image has but that is not
> relevant to grep (mbrlen doesn't correctly handle a call with a len of
> 0).

Thanks for responding.
This reply (via the above) marks this issue as a non-bug and closes it.

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Caleb Zulawski <caleb.zulawski <at> gmail.com>
To: bug-grep <at> gnu.org
Subject: Re: bug#63533: test-mbrlen5.sh failure
Date: Wed, 17 May 2023 21:09:02 -0400

Thanks, this makes sense.  The configure file has the following:

# grep never invokes mbrtowc or mbrlen on empty input,
# so don't worry about this common bug,
# as working around it would merely slow grep down.
gl_cv_func_mbrtowc_empty_input='assume yes’

Isn’t this test too strict, then?  Or is there some way to disable/allow failure for this particular test?  It seems like it should not prevent a build.  Thanks.

> On May 16, 2023, at 2:55 AM, Carlo Arenas <carenas <at> gmail.com> wrote:
> 
> That is a test for a bug that your system image has but that is not
> relevant to grep (mbrlen doesn't correctly handle a call with a len of
> 0).
> 
> Carlo
> 
> 
> 
> 

Message #24 received at 63533 <at> debbugs.gnu.org (full text, mbox):

From: Carlo Marcelo Arenas Belón <carenas <at> gmail.com>
To: Caleb Zulawski <caleb.zulawski <at> gmail.com>
Cc: 63533 <at> debbugs.gnu.org
Subject: Re: bug#63533: test-mbrlen5.sh failure
Date: Wed, 17 May 2023 21:46:52 -0700

[Message part 1 (text/plain, inline)]

On Wed, May 17, 2023 at 09:09:02PM -0400, Caleb Zulawski wrote:
> 
> Isn’t this test too strict, then?

It shouldn't had been included with the release; the attached patch
should help with that for future releases.

> Or is there some way to disable/allow failure for this particular test?

In your build process you could force to skip by doing :

  echo "exit 77" > gnulib-tests/test-mbrlen5.sh

> It seems like it should not prevent a build.

it does not; the build finished, and the tests for grep finished successfully
as well.

if you read your log output, will see this is part of the gnulib tests.

Carlo

[0001-gnulib-avoid-mbrlen-tests.patch (text/x-patch, attachment)]

Message #27 received at 63533 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Carlo Marcelo Arenas Belón <carenas <at> gmail.com>
Cc: Caleb Zulawski <caleb.zulawski <at> gmail.com>, 63533 <at> debbugs.gnu.org
Subject: Re: bug#63533: test-mbrlen5.sh failure
Date: Thu, 18 May 2023 22:09:38 +0200

On Thu, May 18, 2023 at 2:44 PM Carlo Marcelo Arenas Belón
<carenas <at> gmail.com> wrote:
> On Wed, May 17, 2023 at 09:09:02PM -0400, Caleb Zulawski wrote:
> >
> > Isn’t this test too strict, then?
>
> It shouldn't had been included with the release; the attached patch
> should help with that for future releases.

Thanks for looking into this, Carlo.

However, I think we should not limit the gnulib tests that are run via
grep just to accommodate systems with broken code, even when grep
happens not to exercise the broken code path.

Message #30 received at 63533 <at> debbugs.gnu.org (full text, mbox):

From: Carlo Marcelo Arenas Belón <carenas <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: Caleb Zulawski <caleb.zulawski <at> gmail.com>, 63533 <at> debbugs.gnu.org
Subject: Re: bug#63533: test-mbrlen5.sh failure
Date: Fri, 19 May 2023 12:43:17 -0700

[Message part 1 (text/plain, inline)]

On Thu, May 18, 2023 at 10:09:38PM +0200, Jim Meyering wrote:
> On Thu, May 18, 2023 at 2:44 PM Carlo Marcelo Arenas Belón
> <carenas <at> gmail.com> wrote:
> > On Wed, May 17, 2023 at 09:09:02PM -0400, Caleb Zulawski wrote:
> > >
> > > Isn’t this test too strict, then?
> >
> > It shouldn't had been included with the release; the attached patch
> > should help with that for future releases.
> 
> Thanks for looking into this, Carlo.
> 
> However, I think we should not limit the gnulib tests that are run via
> grep just to accommodate systems with broken code, even when grep
> happens not to exercise the broken code path.

Make a good point, specially considering that it should only affect systems
that are EOL like Centos 7, Debian 9 or Ubuntu 16.04 (although some of those
might be still supported) and that would be also likely to fail for other
reasons (ex: not being Y2K38 safe).

I think though, for consistency, the attached should be applied instead.  A
snapshot build with it shows 3 failing gnulib tests when tested in
gcc45.fsffrance.org.

Carlo

[0001-gnulib-allow-mbrtowc-tests.patch (text/x-patch, attachment)]

Message #33 received at 63533 <at> debbugs.gnu.org (full text, mbox):

From: Carlo Arenas <carenas <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: Caleb Zulawski <caleb.zulawski <at> gmail.com>, 63533 <at> debbugs.gnu.org
Subject: Re: bug#63533: test-mbrlen5.sh failure
Date: Fri, 19 May 2023 18:07:05 -0700

On Fri, May 19, 2023 at 12:43 PM Carlo Marcelo Arenas Belón
<carenas <at> gmail.com> wrote:
>
> On Thu, May 18, 2023 at 10:09:38PM +0200, Jim Meyering wrote:
> > On Thu, May 18, 2023 at 2:44 PM Carlo Marcelo Arenas Belón
> > <carenas <at> gmail.com> wrote:
> > > On Wed, May 17, 2023 at 09:09:02PM -0400, Caleb Zulawski wrote:
> > > >
> > > > Isn’t this test too strict, then?
> > >
> > > It shouldn't had been included with the release; the attached patch
> > > should help with that for future releases.
> >
> > Thanks for looking into this, Carlo.
> >
> > However, I think we should not limit the gnulib tests that are run via
> > grep just to accommodate systems with broken code, even when grep
> > happens not to exercise the broken code path.
>
> Make a good point, specially considering that it should only affect systems
> that are EOL like Centos 7

One correction here though, CentOS 7[1] has still about 1 year of
shelf life left, which is probably why conda is still using it as base
of its image.

Carlo

[1] https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.