GNU bug report logs - #62647
[INSTALL] grep: re-fix Y2038 bug on glibc 2.34+ x86, ARM

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 62647 in the body.
You can then email your comments to 62647 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: Paul Eggert <eggert <at> cs.ucla.edu>
To: bug-grep <at> gnu.org
Cc: Paul Eggert <eggert <at> cs.ucla.edu>
Subject: [INSTALL] grep: re-fix Y2038 bug on glibc 2.34+ x86, ARM
Date: Mon,  3 Apr 2023 10:33:11 -0700

The meaning of AC_SYS_LARGEFILE has changed to no longer even try
to use wider time_t if available.  So use AC_SYS_YEAR2038 as well.
A more-aggressive change would be to use the next Autoconf’s
AC_SYS_YEAR2038_REQUIRED but at least let’s restore the grep 3.8
behavior.
* NEWS: Mention this.
* bootstrap.conf: Add year2038.
---
 NEWS           | 4 ++++
 bootstrap.conf | 1 +
 2 files changed, 5 insertions(+)

diff --git a/NEWS b/NEWS
index 6ebade3..060e938 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,10 @@ GNU grep NEWS                                    -*- outline -*-
   grep 3.8, in that patterns like \w and \b use ASCII rather than
   Unicode interpretations.
 
+  grep no longer fails on files dated after the year 2038,
+  when running on 32-bit x86 and ARM hosts using glibc 2.34+.
+  [bug introduced in grep 3.9]
+
 
 * Noteworthy changes in release 3.10 (2023-03-22) [stable]
 
diff --git a/bootstrap.conf b/bootstrap.conf
index 50948a6..ec48c37 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -102,6 +102,7 @@ windows-stat-inodes
 xalloc
 xbinary-io
 xstrtoimax
+year2038
 '
 gnulib_name=libgreputils
 
-- 
2.37.2

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

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 62647 <at> debbugs.gnu.org
Subject: Re: bug#62647: [INSTALL] grep: re-fix Y2038 bug on glibc 2.34+ x86,
 ARM
Date: Mon, 3 Apr 2023 10:52:35 -0700

On Mon, Apr 3, 2023 at 10:34 AM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> The meaning of AC_SYS_LARGEFILE has changed to no longer even try
> to use wider time_t if available.  So use AC_SYS_YEAR2038 as well.
> A more-aggressive change would be to use the next Autoconf’s
> AC_SYS_YEAR2038_REQUIRED but at least let’s restore the grep 3.8
> behavior.
> * NEWS: Mention this.
> * bootstrap.conf: Add year2038.
> ---
>  NEWS           | 4 ++++
>  bootstrap.conf | 1 +
>  2 files changed, 5 insertions(+)
>
> diff --git a/NEWS b/NEWS
> index 6ebade3..060e938 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -10,6 +10,10 @@ GNU grep NEWS                                    -*- outline -*-
>    grep 3.8, in that patterns like \w and \b use ASCII rather than
>    Unicode interpretations.
>
> +  grep no longer fails on files dated after the year 2038,
> +  when running on 32-bit x86 and ARM hosts using glibc 2.34+.
> +  [bug introduced in grep 3.9]
> +
>
>  * Noteworthy changes in release 3.10 (2023-03-22) [stable]
>
> diff --git a/bootstrap.conf b/bootstrap.conf
> index 50948a6..ec48c37 100644
> --- a/bootstrap.conf
> +++ b/bootstrap.conf
> @@ -102,6 +102,7 @@ windows-stat-inodes
>  xalloc
>  xbinary-io
>  xstrtoimax
> +year2038
>  '

Thanks, Paul.
I wanted to see how this would make grep fail, but don't
have convenient access to such hosts. Would this trigger the failure?

  touch -t 203901010000 f
  grep ^ f

How does it fail?

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: 62647 <at> debbugs.gnu.org
Subject: Re: bug#62647: [INSTALL] grep: re-fix Y2038 bug on glibc 2.34+ x86,
 ARM
Date: Mon, 3 Apr 2023 11:20:23 -0700

On 2023-04-03 10:52, Jim Meyering wrote:
> I wanted to see how this would make grep fail, but don't
> have convenient access to such hosts. Would this trigger the failure?
> 
>    touch -t 203901010000 f
>    grep ^ f

Yes, that triggers it. Of course one needs a "touch" and a filesystem 
that supports such timestamps.

Come to think of it, the year2038 module (which coreutils also employs) 
no longer defaults to requiring year2038 support like it used to. It now 
merely enables year2038 support if available. Should we change this in 
Gnulib? This would affect coreutils, grep etc.

Gnulib year2038 became milder when there was pushback about 
AC_SYS_YEAR2038 when it got added to Autoconf. The next Autoconf will 
have AC_SYS_YEAR2038 (which merely tries to get Y2038 support) and 
AC_SYS_YEAR2038_REQUIRED (which requires it).

It's a controversial area because these two modules can change library 
ABIs. I suppose in theory we could add Gnulib modules largefile-required 
and year2038-required, and have coreutils, grep, etc. use these modules. 
However, this doesn't seem worth the hassle, since packages using the 
largefile and year2038 modules are typically compiled with their default 
options. So I'm sort of leaning toward modifying Gnulib's largefile and 
year2038 modules to use the _REQUIRED variants.

Thoughts?


> How does it fail?

It outputs "grep: f: Value too large for defined data type" to stderr 
with exit status 2.

I reproduced the problem by configuring bleeding-edge grep on Ubuntu 
22.10 x86-64 with an i686 compiler and library installed, and 
configuring this way:

./configure CC='gcc -m32' --disable-year2038

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

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 62647 <at> debbugs.gnu.org
Subject: Re: bug#62647: [INSTALL] grep: re-fix Y2038 bug on glibc 2.34+ x86,
 ARM
Date: Mon, 3 Apr 2023 19:49:23 -0700

On Mon, Apr 3, 2023 at 11:20 AM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> On 2023-04-03 10:52, Jim Meyering wrote:
> > I wanted to see how this would make grep fail, but don't
> > have convenient access to such hosts. Would this trigger the failure?
> >
> >    touch -t 203901010000 f
> >    grep ^ f
>
> Yes, that triggers it. Of course one needs a "touch" and a filesystem
> that supports such timestamps.
>
> Come to think of it, the year2038 module (which coreutils also employs)
> no longer defaults to requiring year2038 support like it used to. It now
> merely enables year2038 support if available. Should we change this in
> Gnulib? This would affect coreutils, grep etc.
>
> Gnulib year2038 became milder when there was pushback about
> AC_SYS_YEAR2038 when it got added to Autoconf. The next Autoconf will
> have AC_SYS_YEAR2038 (which merely tries to get Y2038 support) and
> AC_SYS_YEAR2038_REQUIRED (which requires it).
>
> It's a controversial area because these two modules can change library
> ABIs. I suppose in theory we could add Gnulib modules largefile-required
> and year2038-required, and have coreutils, grep, etc. use these modules.
> However, this doesn't seem worth the hassle, since packages using the
> largefile and year2038 modules are typically compiled with their default
> options. So I'm sort of leaning toward modifying Gnulib's largefile and
> year2038 modules to use the _REQUIRED variants.
>
> Thoughts?

I followed that autoconf discussion and am all for requiring y2038
support in the tools we tend.

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

From: arnold <at> skeeve.com
To: jim <at> meyering.net, eggert <at> cs.ucla.edu
Cc: 62647 <at> debbugs.gnu.org
Subject: Re: bug#62647: [INSTALL] grep: re-fix Y2038 bug on glibc 2.34+ x86,
 ARM
Date: Tue, 04 Apr 2023 00:35:46 -0600

Jim Meyering <jim <at> meyering.net> wrote:

> Thanks, Paul.
> I wanted to see how this would make grep fail, but don't
> have convenient access to such hosts. Would this trigger the failure?
>
>   touch -t 203901010000 f
>   grep ^ f
>
> How does it fail?

Why in the world does grep even care about timestamps on files?

Thanks,

Arnold

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: arnold <at> skeeve.com, jim <at> meyering.net
Cc: 62647 <at> debbugs.gnu.org
Subject: Re: bug#62647: [INSTALL] grep: re-fix Y2038 bug on glibc 2.34+ x86,
 ARM
Date: Mon, 3 Apr 2023 23:39:30 -0700

On 2023-04-03 23:35, arnold <at> skeeve.com wrote:
> Why in the world does grep even care about timestamps on files?

The same reason 'awk' does. grep calls stat, fstat, etc., and the call 
fails with errno == EOVERFLOW if the file's timestamp is past the year 2038.

For the same reason I expect that awk, too, should use AC_SYS_YEAR2038 
or its equivalent.

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

From: arnold <at> skeeve.com
To: jim <at> meyering.net, eggert <at> cs.ucla.edu, arnold <at> skeeve.com
Cc: 62647 <at> debbugs.gnu.org
Subject: Re: bug#62647: [INSTALL] grep: re-fix Y2038 bug on glibc 2.34+ x86,
 ARM
Date: Tue, 04 Apr 2023 00:43:03 -0600

Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> On 2023-04-03 23:35, arnold <at> skeeve.com wrote:
> > Why in the world does grep even care about timestamps on files?
>
> The same reason 'awk' does. grep calls stat, fstat, etc., and the call 
> fails with errno == EOVERFLOW if the file's timestamp is past the year 2038.
>
> For the same reason I expect that awk, too, should use AC_SYS_YEAR2038 
> or its equivalent.

Wow!  That's all news to me!

I will have to look into this.

Thanks,

Arnold

Previous Next

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