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

2021-09-16 Thread Aurelien Jarno
On 2021-09-15 00:06, Aurelien Jarno wrote:
> 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/<>/dist/include -I/<>/dist/public/coreconf 
> > > -I/<>/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 '/<>/nss/coreconf/nsinstall'
> > > | make[1]: *** [debian/rules:100: override_dh_auto_build] Error 2
> > > | make[1]: Leaving directory '/<>'
> > > | 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.

Note that the patch I submitted has been accepted, so this won't be
reverted.

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



[Git][glibc-team/glibc][sid] 2 commits: Nitpick: format the messages consistently

2021-09-16 Thread Aurelien Jarno (@aurel32)


Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc


Commits:
5b123cf4 by Aurelien Jarno at 2021-09-15T08:03:07+02:00
Nitpick: format the messages consistently

- - - - -
a86df9fe by Aurelien Jarno at 2021-09-16T22:35:49+02:00
debian/debhelper.in/libc.preinst: make sure USE_DEBCONF cant be defined 
from the environment.

- - - - -


2 changed files:

- debian/changelog
- debian/debhelper.in/libc.preinst


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/-/compare/200a4d3ac16c33a2d033e631f021f25d16ac1b1f...a86df9fe0fc420dab6097d14de45442c99fe38d7

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/-/compare/200a4d3ac16c33a2d033e631f021f25d16ac1b1f...a86df9fe0fc420dab6097d14de45442c99fe38d7
You're receiving this email because of your account on salsa.debian.org.




Bug#994510: libunwind8 abuses setcontext() causing SIGSEGV on i386 with glibc >= 2.32

2021-09-16 Thread Aurelien Jarno
Package: libunwind8
Version: 1.3.2-2
Severity: grave
Tags: upstream
X-Debbugs-Cc: debian-glibc@lists.debian.org

Following the glibc 2.32 upload to unstable, the autopkgtest of the
rspamd package fails on i386, due to a segmentation fault when starting
the daemon [1].

After digging, it appears that the problem is due to libunwind and the
following upstream glibc change [2]:

| commit 15eab1e3e89129ab3ed03f5bdc3415b26e9caeb9 (master)
| Author: H.J. Lu 
| Date:   Sat Feb 1 05:44:55 2020 -0800
| 
| i386: Don't unnecessarily save and restore EAX, ECX and EDX [BZ# 25262]
| 
| On i386, since EAX, ECX and EDX are caller-saved, there are no need
| to save and restore EAX, ECX and EDX in getcontext, setcontext and
| swapcontext.  They just need to clear EAX on success.  The extra
| scratch registers are needed to enable CET.
| 
| Tested on i386.
| 
| Reviewed-by: Adhemerval Zanella 


Basically EAX, ECX and EDX and are not saved anymore across a
getcontext() / setcontext() sequence, and more importantly they are not
restored in setcontext() which is used by libunwind to restore a context
after an exception. In that case, all the registers have to be restored,
including the caller-saved one.

It happens that libunwind shall not have used setcontext() there, but
rather defined its own implementation like its already done for
getcontext() as the behaviour of setcontext() is unspecified when passed
an ucp argument obtained from different sources than getcontext() or
makecontext(). Quoting the GNU libc manual:

| If the context was created by a call to a signal handler or from any
| other source then the behaviour of setcontext is unspecified.

Quoting POSIX.1-2004 (last version before it got removed):

| The effects of passing a ucp argument obtained from any other source
| are unspecified.

Note that upstream bug #69 might be relevant there [3].


[1] https://ci.debian.net/data/autopkgtest/testing/i386/r/rspamd/15290363/log.gz
[2] 
https://sourceware.org/git/?p=glibc.git;a=commit;h=15eab1e3e89129ab3ed03f5bdc3415b26e9caeb9
[3] https://github.com/libunwind/libunwind/issues/69



Upcoming stable point release (11.1)`

2021-09-16 Thread Adam D. Barratt
Hi,

The first point release for "bullseye" (11.1) is scheduled for
Saturday, October 9th. Processing of new uploads into bullseye-
proposed-updates will be frozen during the preceding weekend.

Regards,

Adam



Upcoming oldstable point release (10.11)

2021-09-16 Thread Adam D. Barratt
Hi,

The next point release for "buster" (10.11) is scheduled for Saturday,
October 9th. Processing of new uploads into buster-proposed-updates
will be frozen during the preceding weekend.

Regards,

Adam