Glibc 2.33 update

[romulasry]

https://sourceware.org/git/?p=glibc.git;a=commit;h=9826b03b747b841f5fc6de2054bf1ef3f5c4bdf3

https://www.phoronix.com/scan.php?page=news_item&px=GNU-C-Library-2.33

[phmccarty]

Work on this update is in progress. Current status is that glibc 2.33 builds okay, but we are running into some crashes at runtime. The root cause there is still TBD.

[phmccarty]

More details about the crashes:

• The initial crashes were in glibc's NSS code, but I think I've fixed that issue by adjusting the package's stateless.patch, which required adjustment for this upstream commit. We will test more to confirm that my changes fix that issue.
• Another crash occurs with tar during package builds while extracting source archives via %setup. As an experiment, I recompiled tar to disable static linkage, and with the resulting /usr/bin/tar, the crash no longer occurs. Not sure what might be happening here, but using a dynamically-linked tar appears to be a reliable workaround until we learn more.

[fenrus75]

the tar crash is in nss readline function...

…

On Tue, Apr 20, 2021, 19:01 Patrick McCarty ***@***.***> wrote: More details about the crashes: - The initial crashes were in glibc's NSS code, but I think I've fixed that issue by adjusting the package's stateless.patch, which required adjustment for this upstream commit <https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=299210c1fa67e2dfb564475986fce11cd33db9ad>. We will test more to confirm that my changes fix that issue. - Another crash occurs with tar during package builds while extracting source archives via %setup. As an experiment, I recompiled tar to disable static linkage, and with the resulting /usr/bin/tar, the crash no longer occurs. Not sure what might be happening here, but it appears to be a reliable workaround. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2270 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ54FKNYZSXXHUH6B2FVDTTJYWZLANCNFSM4W5KI5WQ> .

[phmccarty]

Thanks. Here's the backtrace I see when debugging the build of helloworld with the new glibc. I populated the mock buildroot with glibc and tar debuginfo, and then ran bzip2 -dc /builddir/build/SOURCES/helloworld-4.tar.bz2 > foo.tar; gdb --args tar -tf foo.tar in the buildroot.

(gdb) run
Starting program: /usr/bin/tar -tf foo.tar

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7f13f4e in __GI___nss_readline (fp=fp@entry=0x7ffff7cb92a0, buf=buf@entry=0x5b1790 "mockbuild:x:1010:1010::/builddir:/bin/bash\n", len=len@entry=1024,
    poffset=poffset@entry=0x7fffffffdd30) at nss_readline.c:68
68            while (isspace (*p))
(gdb) bt
#0  0x00007ffff7f13f4e in __GI___nss_readline (fp=fp@entry=0x7ffff7cb92a0, buf=buf@entry=0x5b1790 "mockbuild:x:1010:1010::/builddir:/bin/bash\n", len=len@entry=1024,
    poffset=poffset@entry=0x7fffffffdd30) at nss_readline.c:68
#1  0x00007ffff7fc8659 in internal_getent (stream=0x7ffff7cb92a0, result=result@entry=0x5ad7a0 <resbuf>, buffer=buffer@entry=0x5b1790 "mockbuild:x:1010:1010::/builddir:/bin/bash\n",
    buflen=buflen@entry=1024, errnop=errnop@entry=0x5af870) at nss_files/files-XXX.c:156
#2  0x00007ffff7fc88fe in _nss_files_getpwnam_r (name=0x7ffff7fd8509 "root", result=0x5ad7a0 <resbuf>, buffer=0x5b1790 "mockbuild:x:1010:1010::/builddir:/bin/bash\n", buflen=1024,
    errnop=0x5af870) at nss_files/files-pwd.c:35
#3  0x00000000004c920d in __getpwnam_r (name=name@entry=0x7ffff7fd8509 "root", resbuf=resbuf@entry=0x5ad7a0 <resbuf>, buffer=0x5b1790 "mockbuild:x:1010:1010::/builddir:/bin/bash\n",
    buflen=buflen@entry=1024, result=result@entry=0x7fffffffde60) at ../nss/getXXbyYY_r.c:315
#4  0x00000000004c8dac in getpwnam (name=name@entry=0x7ffff7fd8509 "root") at ../nss/getXXbyYY.c:134
#5  0x00000000004219ef in uname_to_uid (uname=uname@entry=0x7ffff7fd8509 "root", uidp=uidp@entry=0x5abbd4 <current_stat_info+116>) at names.c:546
#6  0x000000000041c0e0 in decode_header (header=0x7ffff7fd8400, stat_info=stat_info@entry=0x5abb60 <current_stat_info>, format_pointer=format_pointer@entry=0x5ab720 <current_format>,
    do_user_group=do_user_group@entry=1) at list.c:687
#7  0x000000000041d824 in read_and (do_something=0x41dd50 <list_archive>) at list.c:194
#8  0x00000000004032f4 in main (argc=<optimized out>, argv=<optimized out>) at tar.c:2815

[thiagomacieira]

isspace is a macro that reads from the ctype globals and p is supposed to come from buf:

      char *p = buf;
      while (isspace (*p))
        ++p;

We see buf on entry had a proper string content, so I don't see how it could have become invalid. Is it possible the problem is actually isspace ?

# define __isctype(c, type) \
  ((*__ctype_b_loc ())[(int) (c)] & (unsigned short int) type)
# define isspace(c)	__isctype((c), _ISspace)

So maybe __ctype_b_loc is returning a null pointer.

[phmccarty]

Looks like the crash stems from the fact that we statically link the tar binary. I found a hint from tar's build log:

/usr/bin/ld: map.o: in function `name_to_uid':
/builddir/build/BUILD/tar-1.34/src/map.c:192: warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

So, tar would continue to work as expected until the glibc version changes. In this case, we want to update to glibc 2.33, so the use of a tar statically linked to glibc 2.31 is incompatible.

To avoid the crash, we are making tar non-static again. That change will land in the next build.

I will do some more testing before we update to glibc 2.33, but the tar crash is the only problem we've run into so far.

[phmccarty]

My testing with glibc 2.33 looks good, so we are integrating this update for the next build.

[phmccarty]

glibc 2.33 landed in release 34560.