[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#993973: nss FTBFS with glibc 2.32: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull]



On 2021-09-09 00:52, Aurelien Jarno wrote:
> control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=27476
> 
> On 2021-09-09 00:21, Helmut Grohne wrote:
> > Source: nss
> > Version: 2:3.70-1
> > Severity: serious
> > Tags: ftbfs
> > X-Debbugs-Cc: debian-glibc@lists.debian.org
> > 
> > A native build of nss now fails as follows:
> > 
> > | x86_64-linux-gnu-gcc -o OBJS/nsinstall.o -c -std=c99 -g -g -fPIC   -pipe -ffunction-sections -fdata-sections -DHAVE_STRERROR -DLINUX -Dlinux -Wall -Wshadow -Werror -DXP_UNIX -DXP_UNIX -DDEBUG -UNDEBUG -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_POSIX_SOURCE -DSDB_MEASURE_USE_TEMP_DIR -D_REENTRANT -DDEBUG -UNDEBUG -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_POSIX_SOURCE -DSDB_MEASURE_USE_TEMP_DIR -D_REENTRANT -DNSS_NO_INIT_SUPPORT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -I/<<PKGBUILDDIR>>/dist/include -I/<<PKGBUILDDIR>>/dist/public/coreconf -I/<<PKGBUILDDIR>>/dist/private/coreconf  nsinstall.c
> > | nsinstall.c: In function ‘main’:
> > | nsinstall.c:70:16: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull]
> > |    70 | #define GETCWD getcwd
> > |       |                ^
> > | nsinstall.c:239:8: note: in expansion of macro ‘GETCWD’
> > |   239 |  cwd = GETCWD(0, PATH_MAX);
> > |       |        ^~~~~~
> > | In file included from nsinstall.c:20:
> > | /usr/include/unistd.h:520:14: note: in a call to function ‘getcwd’ declared with attribute ‘write_only (1, 2)’
> > |   520 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur
> > |       |              ^~~~~~
> > | nsinstall.c:70:16: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull]
> > |    70 | #define GETCWD getcwd
> > |       |                ^
> > | nsinstall.c:246:13: note: in expansion of macro ‘GETCWD’
> > |   246 |     todir = GETCWD(0, PATH_MAX);
> > |       |             ^~~~~~
> > | In file included from nsinstall.c:20:
> > | /usr/include/unistd.h:520:14: note: in a call to function ‘getcwd’ declared with attribute ‘write_only (1, 2)’
> > |   520 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur
> > |       |              ^~~~~~
> > | cc1: all warnings being treated as errors
> > | make[2]: *** [../../coreconf/rules.mk:292: OBJS/nsinstall.o] Error 1
> > | make[2]: Leaving directory '/<<PKGBUILDDIR>>/nss/coreconf/nsinstall'
> > | make[1]: *** [debian/rules:100: override_dh_auto_build] Error 2
> > | make[1]: Leaving directory '/<<PKGBUILDDIR>>'
> > | make: *** [debian/rules:195: build] Error 2
> > | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
> > 
> > It looks very much like this is due to the glibc 2.32 upload. My reading
> > of man getcwd is that the call of nss is legit (as a glibc extension).
> > Maybe this is a glibc bug?
> 
> This is indeed partially a glibc bug, already reported upstream there:
> https://sourceware.org/bugzilla/show_bug.cgi?id=27476
> 
> Note however that the feature of calling getcwd(NULL, >0) is a GNU
> extension, and that the above code doesn't define _GNU_SOURCE, so this
> is also a bug in the package.
> 
> Please also note that there are discussion to deprecate the support of
> size > 0 when buf is NULL:
> https://sourceware.org/bugzilla/show_bug.cgi?id=26545

I have uploaded a version with a temporary fix, until upstream takes a
decision. If upstream decides to drop this part of the GNU extension,
this patch will be removed from the Debian package, so that the
behaviour is consistent between distribution. Of course in that case
the documentation will have to be fixed accordingly. The packages using
this extension will have to get fixed, just like some distributions
using glibc >= 2.32 started to do.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: