Bug#296490: libc6: getgrnam segfault (using __nscd_getgrnam_r)

* Tom Parker: > Calling getgrnam() with a NULL argument, with group in > /etc/nsswitch.conf set to 'compat' can cause a segfault in > __nscd_getgrnam_r due to a lack of a check for a NULL string before > doing strlen(). Is there any standard that defines the behavior of getgrnam(NULL)? -- To U

Bug#308341: glibc-doc: SO_RCVBUF documented as size_t, but is int in Linux.

* Teddy Hogeborn: > In "(libc)Socket-Level Options", SO_RCVBUF is documented as having a > type "size_t". In Linux, it is of type "int". The man page socket(7) > does not say what type it is. The same goes for SO_SNDBUF. According to the kernel and Stevens, it's an indeed an int. So the docum

Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap

* Vesselin Peev: > #include > int main() > { > gethostbyname("www.google.com"); > return 0; > } > number of leaked objects: 49 This is not a problem, unless this number grows with each gethostbyname invocation. The underlying programming pattern which causes this is quite common an

Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap

* Vesselin Peev: >> This is not a problem, unless this number grows with each >> gethostbyname invocation. The underlying programming pattern which >> causes this is quite common and perfectly harmless (if you get the >> threading issues right, of coruse). > > Just tested it in a loop, the leaks

Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap

* Vesselin Peev: > I'm thinking of submitting a wish about better handling, You could reuse this bug report (downgrade it to wishlist, reassign if necessary). > if possible with the mudflap architecture, of internal data > allocated by libc. Proper handling should of course include no > "unacces

Bug#326832: libc6: valgrind reports use of uninitialized values

reassign 326832 valgrind thanks * Justin Pryzby: > valgrind reports 13 instances of "Conditional jump or move depends on > uninitialised value(s)" using the new libc6 in testing, for a trivial > program which just calls exit(0). This is valgrind-2.4.0-3. This means that the valgrind suppression

Bug#600667: eglibc: cve-2010-3847 dynamic linker expands $ORIGIN in setuid library search path

* Aurelien Jarno: > I have just committed the fix, I am planning to do an upload soon to > unstable. Do you think we should also fix it in stable? via a security > release? FYI, I have uploaded eglibc 2.11.2-6+squeeze1 to testing-security. -- To UNSUBSCRIBE, email to debian-glibc-requ...@list

Re: glibc_2.7-18lenny6_source.changes REJECTED

* Debian FTP Masters: > Reject Reasons: > source only uploads are not supported. > > Notes: > Mapping stable-security to proposed-updates. Ahem. Should I upload a newer version to stable-proposed-updates, or is this a spurious error message? -- To UNSUBSCRIBE, email to debian-glibc-requ...@li

squeeze upload for eglibc due to DSA-2122-2

I would like to make an upload of eglibc to address DSA-2122-2 (the first round of patches for the $ORIGIN/LD_AUDIT issue does not cover all corner cases, unfortunately). The changes match those in 2.7-18lenny7, which are based almost verbatim on the upstream patches (except for whitespace changes

Bug#609756: vsnprintf segfaults on second attempt with alloca

* Andrew Buckeridge: > int vfprint(int fdout, const char *fmt, va_list ap) > { > int i=NONSTDBUF; > i=vfnprint(fdout, i, fmt, ap); > if(i<-1) > i=vfnprint(fdout, 1-i, fmt, ap); > return i; > } va_copy seems to be missin

Bug#609756: vsnprintf segfaults on second attempt with alloca

ffects subsequent va_arg invocations in the caller. > Does this break C89 and C90? Some systems have got __va_copy. There's probably an autoconf test for this. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-9

Bug#457472: openssh-client: ssh resolves some hosts to 1.0.0.0

* Colin Watson: >> [*] 1.0.0.0 isn't even a valid IP address, is it? > > Depends on the situation. You wouldn't want to give a host that > address, Why not? Subnet zero is no longer reserved. The whole /8 is currently not assigned, but that's a different matter. > but it might be quite reasona

Bug#482902: please provide libc6-hppa64 and libc6-hppa64-dev packages

* Thibaut VARENE: > I'm not sure I understand this correctly though: what's needed right > now is a debian-packaged etch-supported kernel (ie, 2.6.18 if my memory > serves me right?) that works on hppa? Is it any different that the > kernel package shipped with etch? (I suspect it is since the lat

Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

* brian m. carlson: > The glibc stub resolver is vulnerable to CVE-2008-1447, according to DSA > 1605. Since the vast majority of network-using programs use glibc as a > resolver, this vulnerability affects virtually any network-using > program, hence the severity. libc6 should not be released w

Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

* Aurelien Jarno: > IMHO, the UDP randomization commit has to be backported to the etch > kernel. The advantage of this solution, is that it potentially fixes > other bugs/vulnerabilities in other protocols/programs using UDP. Currently, there is no suitable patch to backport. I hope that improv

Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

* Aurelien Jarno: >> Currently, there is no suitable patch to backport. I hope that improved >> port randomization will be available shortly. > > You mean a patch for the kernel? Yes, one for the kernel, and one for the transaction ID generation in the libc resolver, too. (Oh, and "shortly" ==

Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

reopen 491809 thanks * Pierre Habouzit: > Kaminsky agrees confirm the issue, so I can say for sure that the > glibc isn't vulnerable to the attack he describes, as it needs a > resolver that caches additionnal RRs, which the glibc doesn't do. > As of attacks that would use non randomized sou

Bug#382175: Sun RPC libraries and other stories

* Simon Phipps: > On Nov 5, 2008, at 23:23, Michael Banck wrote: >> >> - portmap.c >> >> /* >> @(#)portmap.c 2.3 88/08/11 4.0 RPCSRC >> static char sccsid[] = "@(#)portmap.c 1.32 87/08/06 Copyr 1984 Sun >> Micro"; >> */ >> >> This is portmap-6.0, from http://neil.brown.name/portmap/ > > Is this

Bug#382175: Sun RPC libraries and other stories

* Simon Phipps: > On Nov 18, 2008, at 03:52, Ben Hutchings wrote: > >> Many of the functions in portmap.c seem to correspond to >> rpcbind (usr/src/cmd/rpcbind) in OpenSolaris: > > Is it just the function prototypes that are derived, or is there > derived source defining them too? >From our portm

Security-related patches for wheezy (and squeeze LTS)

I would like to send a few security-related backports frpm upstream your way. On the security side, we won't do a DSA for any of those (probably; I still haven't got a complete handle on what's missing). But it's certainly wheezy-updates material. Should I just send the patches, or do you want di

Bug#717544: CVE-2013-2207: Remove pt_chown

retitle 717544 CVE-2013-2207: Remove pt_chown thanks Can we please make another attempt at removing pt_chown, either completely or by removing the SUID bit? The current devpts file system is set up in such a way that this is not necessary. Fedora and Red Hat Enterprise Linux 7 already ship witho

Bug#717544: CVE-2013-2207: Remove pt_chown

* Samuel Thibault: > Hello, > > Florian Weimer, le Thu 06 Aug 2015 07:15:01 +0200, a écrit : >> retitle 717544 CVE-2013-2207: Remove pt_chown >> thanks >> >> Can we please make another attempt at removing pt_chown, either >> completely or by removing the SU

Bug#802256: Backport tls_dtor_list hardening

Package: libc6 Version: 2.19-18+deb8u1 Please backport this upstream hardening patch to jessie (wheezy does not have this feature yet): https://sourceware.org/bugzilla/show_bug.cgi?id=19018 https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f586e1328681b400078c995a0bb6ad301ef73549 Also rec

Bug#815974: Segmentation fault in libresolv triggered by php5-fpm

* Aurelien Jarno: > On 2016-02-26 13:31, Carlos O'Donell wrote: >> On Fri, Feb 26, 2016 at 7:46 AM, Fabian Niepelt >> wrote: >> > This is the correct output, the older one contains a test I thought was >> > in an endless loop but succeeded after a few minutes. >> >> The glibc maintainers for de

Bug#519774: libc6: causes many programs not to be able to resolve dns addresses

* Mark Kamichoff: > Hi - > >> The problem is that the DNS server of your ISP does not conform to the >> RFC and only answer to the query with a void answer. It never >> answer to the A query, so the glibc resolver can only conclude the >> whole query has no answer. > > Just a thought, many D

Bug#568913: depends on nonexistent glibc-2.11-1

> Package: locales > > Now there are TWO experimental packages. > # apt-cache policy locales > locales: > Installed: 2.10.2-5 > Candidate: 2.11-0exp4 > Version table: > 2.11-0exp4 0 > 990 http://ftp.tw.debian.org experimental/main Packages > 2.11-0exp2 0 > 990 http:/

Bug#679828: libc6: No easy way of enabling DNSSEC validation aka RES_USE_DNSSEC

* Matthew Grant: > From my investigations this can only be enabled by recompiling each bit > of software to set the RES_USE_DNSSEC flag in _res.options, as well as > RES_USE_EDNS0. (Please see racoon bug #679483). The enablement method > is from openssh 6.0p1, openbsd-compat/getrrsetbyname.c Th

Bug#783210: [PATCH] nscd_stat.c: make the build reproducible

On 03/09/2016 05:30 PM, Mike Frysinger wrote: would it be so terrible to properly marshall this data ? Ximin Luo and I discussed this and I wonder if it is possible to read out the libc.so.6 build ID if it is present. It should indirectly call all the layout dependencies and be reasonably e

Bug#824429: libc6: In certain locale combinations mbsrtowcs cannot recover from EILSEQ

tags 824429 upstream forwarded 824429 https://sourceware.org/bugzilla/show_bug.cgi?id=20617 thanks * Christoph Biedl: > It might be questionable whether this is a bug in glibc at all. But at > least it's surprising behaviour. > > The reproducer below calls mbstowcs two times, first time with > an

Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

* Fernando Santagata: > One month ago everything worked fine on my Debian sid computer. > After an update/dist-upgrade cycle in which libc6 was updated I > started noticing some malfunctions. Did you upgrade the kernel at the same time?

Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

* Aurelien Jarno: > Hmm, rsync doesn't use libpthread, so that clearly rules out a > libpthread issue. That said, all the example you gave fail to allocate > the memory correctly, either through malloc (glibc) or mmap (kernel) > which returns -ENOMEM. This points to either a kernel issue, or a > l

Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

* Fernando Santagata: >> Usually it manifests in premature OOM killer invocations, but maybe >> something the reporter's system configuration changes that (perhaps it >> runs with vm.overcommit_memory=2?). > > That's it. I found this in /var/log/kern.log at the time I run a program > that crashed:

Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

* Aurelien Jarno: > On 2016-09-27 13:44, Florian Weimer wrote: >> * Aurelien Jarno: >> >> > Hmm, rsync doesn't use libpthread, so that clearly rules out a >> > libpthread issue. That said, all the example you gave fail to allocate >> > the memory c

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

* Petter Reinholdtsen: > Something like this should work, I guess: > > if [ ! -f /etc/hostid ]; then >if [ -e /sys/class/dmi/id/product_uuid ]; then >sethostidfromuuid $(cat /sys/class/dmi/id/product_uuid) >else > dd if=/dev/urandom bs=1 count=4 of=/etc/hostid 2>/dev/null >

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

* Petter Reinholdtsen: > [Florian Weimer] >> That's not very different from /etc/machine-id, isn't it? > > Ah, thank you very much for bringing this systemd setting to my > attention. I was not aware of it. > > I agree that it seem very similar in purpose

Re: segfault in errx

* Michael Meskes: > I recently learned that ul (from bsdmainutils) segfaults when run > against the attached file. Some debugging shows that the segfault > happens when cleaning up in errx(): > > michael@feivel:~$ ul ul.segf > ul: unknown escape sequence in input: 33, 135 > Speicherzugriffsfehler

Re: segfault in errx

* Florian Weimer: > * Michael Meskes: > >> I recently learned that ul (from bsdmainutils) segfaults when run >> against the attached file. Some debugging shows that the segfault >> happens when cleaning up in errx(): >> >> michael@feivel:~$ ul ul.segf >>

Re: segfault in errx

* Florian Weimer: >> I can reproduce something like this with 2.24-3 on amd64. valgrind >> isn't very helpful. > > And it needs a UTF-8 locale (C.UTF-8 will do). Another multi-byte > locale may work as well. Bisecting this with the attache

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

* Michael Stone: > Other platforms have deprecated gethostid, that's the best way forward > for linux, IMO. I agree. It's the most likely outcome if this issue was reported to glibc upstream.

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

* Richard Laager: > Getting back to ZFS and /etc/hostid... I would think that a > randomly-generated /etc/hostid is probably sufficient. Whether that's > done in the libc, spl, or zfs package makes no difference to me. As I tried to explain, the risks of collisions without central coordination lo

Bug#839280: libc6: asprintf(&c, "%F", 1.0) puts 0.00000 in c on raspberry pi zero v1.3.

* Noah Williams: >* What led up to the situation? I was building a robot, and needed a > raspberry pi zero to send a floating point number formatted as a string to an > arduino. >* What exactly did you do (or not do) that was effective (or > ineffective)? I've tried passing bigger n

Bug#858529: libc6: fgets repeats content after fork on stretch only

tags 858529 upstream forwarded 858529 https://sourceware.org/bugzilla/show_bug.cgi?id=20598 thanks * Neil Spring: > if(fork() == 0) { exit(1); } exit flushes the stdio buffers in the child. Upstream concluded that this leads to undefined behavior: | Yes, this is about the exit actually. But

Bug#857909: [libc6-dev] getpid() in child process created using clone(CLONE_VM) returns parent's pid

* John Paul Adrian Glaubitz: > I would suggest filing a bug report to glibc upstream or posting on > their mailing list to ask for feedback. Upstream has since removed the PID cache:

Bug#879093: Segfault in libc6 while using xrdp-sesman on Stretch

* Gilles MOREL: > I repported this bug for the package libc6 because the kernel line let > me think the problem comes from libc6. It's much more likely that xrdp-sesman calls a glibc function on an invalid pointer. > If you want me to provide more log or debugging, please tell me, I > don't real

Bug#969926: glibc: Parsing of /etc/gshadow can return bad pointers causing segfaults in applications

* Moritz Mühlenhoff: > Am Wed, Sep 09, 2020 at 12:30:44PM +0200 schrieb Aurelien Jarno: >> control: forcemerge 967938 969926 >> >> Hi, >> >> On 2020-09-09 02:58, Bernd Zeimetz wrote: >> > Source: glibc >> > Version: 2.28-10 >> > Severity: serious >> > Tags: security upstream patch >> > X-Debbugs

Bug#969926: glibc: Parsing of /etc/gshadow can return bad pointers causing segfaults in applications

* Aurelien Jarno: > On 2021-06-04 20:34, Florian Weimer wrote: >> * Moritz Mühlenhoff: >> >> > Am Wed, Sep 09, 2020 at 12:30:44PM +0200 schrieb Aurelien Jarno: >> >> control: forcemerge 967938 969926 >> >> >> >> Hi, >> >>

Bug#969926: glibc: Parsing of /etc/gshadow can return bad pointers causing segfaults in applications

* Aurelien Jarno: >> > Is it possible to commit those patches to the upstream 2.28 branch? If >> > so, I guess we can simply pull the branch in the Debian package, fixing >> > many other security bugs at the same time. >> >> I'm concerned about the GLIBC_PRIVATE internal ABI change, it causes >>

Re: Preparing for glibc 2.34: library locations

* Michael Hudson-Doyle: > There is another wrinkle of course in that Debian/Ubuntu install these > files to /lib/$multiarch/, not /lib or /lib64 as upstream expects. > > What I've implemented[0] for Ubuntu (only for testing so far) is to > install libc to /lib/$multiarch/libc.so.6, the dynamic lin

Re: Preparing for glibc 2.34: library locations

* Michael Hudson-Doyle: > (but then, dpkg is not > impacted by the symbolic link issue as far as I know). > > Is this problem written up somewhere? I only subscribed to libc-alpha > a few weeks ago. I've written about it in various places. As far as I know, it's specific to how RPM performs pa

/usr/bin/ld.so as a symbolic link for the dynamic loader

I'd like to provide an ld.so command as part of glibc. Today, ld.so can be used to activate preloading, for example. Compared to LD_PRELOAD, the difference is that it's specific to one process, and won't be inherited by subprocesses—something is that exactly what is needed. There is also some use

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

* Paul Wise: > Florian Weimer wrote: > >> I'd like to provide an ld.so command as part of glibc. > > Will this happen in glibc upstream or just in Debian? Upstream, and then Debian. The symbolic link would likely and up in libc-bin in Debian. >> Today, ld.so can b

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

* Bastian Blank: > On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote: >> Right, thanks for providing a concrete example. A (somewhat) portable >> version would look like this: >> ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl &

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

* Theodore Y. Ts'o: > * How does ld.so --preload *work*? The dynamic loader has an array of preloaded sonames, and it processes them before loading the dependencies of the main program. This way, definitions in the preloaded objects preempt definitions in the shared objects. > * Does it modify

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

* Simon McVittie: > On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote: >> Having ld.so as a real command makes the name architecture-agnostic. >> This discourages from hard-coding non-portable paths such as >> /lib64/ld-linux-x86-64.so.2 or even (the non-ABI-comp

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

* Helmut Grohne: > Hi Florian, > > On Fri, Dec 03, 2021 at 06:29:33PM +0100, Florian Weimer wrote: >> We can add a generic ELF parser to that ld.so and use PT_INTERP, as I >> mentioned below. I think this is the way to go. Some care will be >> needed to avoid endles

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

* Aurelien Jarno: > Hi, > > On 2021-12-02 19:51, Florian Weimer wrote: >> I'd like to provide an ld.so command as part of glibc. Today, ld.so can >> be used to activate preloading, for example. Compared to LD_PRELOAD, >> the difference is that it's

Bug#1004577: ldconfig -p coredumps

* Christoph Berg: > Package: libc-bin > Version: 2.33-3 > Severity: important > > In > https://salsa.debian.org/python-team/packages/python-telethon/-/jobs/2413916 > there is a diff generated between the two builds because a core file > from `ldconfig -p` appears as /usr/lib/python3.10/dist-packa

Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

* Alejandro Colomar via Libc-alpha: > Is there an easy way to regenerate that header to get the tatest > syscalls? Maybe a command could be supplied so that users (or at > least distributors) have it easy to regenerate them? Maybe it already > exists but it's not widely known? I have recently b

Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

* Alejandro Colomar: > Hi Florian! > > On 7/25/22 12:38, Florian Weimer wrote: >> * Alejandro Colomar via Libc-alpha: >> >>> Is there an easy way to regenerate that header to get the tatest >>> syscalls? Maybe a command could be supplied so that users (or

Re: static pie: confusion between _DYNAMIC, crt1.o, Scrt1.o

* Samuel Thibault: > Is it not possible to make -static -pie get the same behavior? That'd be > way more orthogonal for people to understand. I think you want -static to mean -static-pie if GCC defaults to PIE, right? That will break a few things that use gcc -static to build binaries for quasi-

Re: static pie: confusion between _DYNAMIC, crt1.o, Scrt1.o

* Samuel Thibault: > Florian Weimer, le lun. 24 oct. 2022 12:11:03 +0200, a ecrit: >> * Samuel Thibault: >> >> > Is it not possible to make -static -pie get the same behavior? That'd be >> > way more orthogonal for people to understand. >> >> I

Re: static pie: confusion between _DYNAMIC, crt1.o, Scrt1.o

* Mike Frysinger via Libc-alpha: > On 24 Oct 2022 13:12, Florian Weimer via Libc-alpha wrote: >> * Samuel Thibault: >> > Florian Weimer, le lun. 24 oct. 2022 12:11:03 +0200, a ecrit: >> >> * Samuel Thibault: >> >> >> >> > Is it not possi

time64 ABI fix coming to upstream glibc

The and headers had a bug that the on-disk structures defined there could change size on some targets when _TIME_BITS was set to 64. This is obviously wrong because the files are not going to magically change their layout because the application accessing them was built in a specific way. We're

Bug#887169: libc6: recent upgrade to 2.26-3 broke Steam games (Civ5)

On 01/15/2018 12:22 AM, Aurelien Jarno wrote: I don't think it is actually the consensus, only Arch Linux has chosen this solution, and building the whole glibc with this option will have an impact of the performances for all binaries, not only the broken Steam ones. I therefore don't think it's

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

* Aurelien Jarno: > I have no idea. On a fast 4-cores amd64 machine and for the 3 flavours > built on amd64, the glibc takes around 20 minutes to build and the > testsuite around 2h to run. This is still rather slow. I see native builds on relatively current hardware taking 2 minutes, plus 12 to

Bug#895981: please cleanup /var/cache/nscd on restart

* Harald Dunkel: > I am using both systemd and sysvinit-core, but I am not sure which one > was active when I ran into this problem. > > Consider a split DNS setup for a remote network. I had started an IPsec > connection to the remote side. /etc/resolv.conf was changed to include > the new intern

Bug#895981: please cleanup /var/cache/nscd on restart

* Carlos O'Donell: > Then each registered file, like /etc/resolv.conf, is watched via > inotify for any changes, and if a change is detected and > finfo->call_res_init was true (and it's true only for resolv.conf) > then we call res_init(). But res_init does not flush the nscd cache, doesn't it?

Bug#897373: libc6: feof(file) always false when forking after read

* David Beniamine: > int do_fork() { > pid_t pid; > > switch (pid = fork()) { > case -1: > fprintf(stderr, "Fork failed\n"); > return -1; > case 0: > exit(-1); Does the issue go away when you call _exit instead of exit?

Bug#897373: libc6: feof(file) always false when forking after read

* David Beniamine: > On Thu, May 10, 2018 at 07:06:03PM +0200, Florian Weimer wrote: >> * David Beniamine: >> >> > int do_fork() { >> > pid_t pid; >> > >> > switch (pid = fork()) { >> > case -1: >> >

Bug#620887: Please add a shm_mkstemp() function

On 05/16/2018 10:25 PM, Jakub Wilk wrote: * Goswin von Brederlow , 2011-04-04, 23:33: int shm_mkstemp(char *template); FWIW, this function is available on OpenBSD: https://man.openbsd.org/shm_mkstemp.3 We have memfd_create nowadays. It's not exactly identical because it creates an unnamed

Bug#900025: /usr/lib/x86_64-linux-gnu/libm.so: invalid ELF header

* Aurelien Jarno: > Now I don't find this common/utils.c file in the simple-scan sources. This looks like a known hplip bug: https://bugzilla.redhat.com/show_bug.cgi?id=1347231 More recent sources try to load libm.so.6 as well. Note that shared objects which use libm (or any libc) functions an

Bug#880846: libc-bin: libnss_compat is deprecated and nsswitch should stop using it on new installation

* Laurent Bigonville: > According to the release note of 2.26, the nss_compat module is > deprecated[0]. > [0]https://sourceware.org/ml/libc-announce/2017/msg1.html I think we made changes so that it is no longer deprecated, by removing the hard NIS dependency. It shouldn't be used by defau

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

* Niels Thykier: > armel/armhf: > > > * Undesirable to keep the hardware running beyond 2020. armhf VM >support uncertain. (DSA) >- Source: [DSA Sprint report] Fedora is facing an issue running armhf under virtualization on arm64:

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

* Luke Kenneth Casson Leighton: > that is not a surprise to hear: the massive thrashing caused by the > linker phase not being possible to be RAM-resident will be absolutely > hammering the drives beyond reasonable wear-and-tear limits. which is > why i'm recommending people try "-Wl,--no-keep-m

Bug#861116: Fixed in glibc 2.28

The issue should be fixed with this upstream commit: commit c402355dfa7807b8e0adb27c009135a7e2b9f1b0 Author: Florian Weimer Date: Tue Jun 26 10:24:52 2018 +0200 libio: Disable vtable validation in case of interposition [BZ #23313] <https://sourceware.org/git/gitweb.cgi?p=glibc.gi

Bug#902851: libc-bin: ldd stopped working with 32-bit binaries on amd64 machine

* Alexandra N. Kossovsky: > Please close this bug. I definitely saw the issue yesterday, but it has > somehow gone today. I'll return to you if I see it again and understand > what triggers it. The related Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=1596312 appears to have been

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

* Paul Gevers: > On Sun, 01 Apr 2018 21:56:33 +0200 Florian Weimer wrote: >> > I have no idea. On a fast 4-cores amd64 machine and for the 3 flavours >> > built on amd64, the glibc takes around 20 minutes to build and the >> > testsuite around 2h to run. >>

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

* Paul Gevers: > Hi Florian, > > On 29-07-18 13:26, Florian Weimer wrote: >> I'm not sure why it is necessary to build glibc three times (unless >> it's impossible to get multi-arch packages into the buildroot). > > I am not sure if I understand what you

Bug#761300: libc6: Printf("%c",'x') does not follow stdio

* Sven Joachim: > This result is rather surprising. After all, "putchar('x')" is supposed > to do the same as "putc('x', stdout)", but here it does not. Can you reproduce this with something newer than 2.13-38+rpi2+deb7u3? Or on something else besides armhf?

Bug#912665: (geen onderwerp)

* Frederik Himpe: > FYI, this is where it crashes: > > #0 0x7fc0172239c6 in _IO_fgets (buf=0x7ffc9b2b1640 " > /dev/aivmhost3-vg/ceph-node1-storage:ceph-ff35163d-b03f-4dbf-a6ce-155730069dc0:4194304:-1:8:8:-1:4096:511:0:511:ZNexTV-ylVb-ltMP-T8Zu-ZklU-cN1I-dETf5o\n", > n=1024, fp=0x1a90030) >

Bug#761300: libc6: putchar does not follow stdio

* Sven Joachim: > Am 14.10.2018 um 13:38 schrieb Florian Weimer: > >> * Sven Joachim: >> >>> This result is rather surprising. After all, "putchar('x')" is supposed >>> to do the same as "putc('x', stdout)", but here

Bug#906917: sem_timedwait could always block and returns ETIMEOUT but decrements the value on i686 architecture

* Андрей Доценко: > The problem occurs only when using semaphores in a library that is not > linked against pthread. Yes, that's expected. Sorry I didn't see this earlier—we have an upstream bug about this: In general, underlinking prod

Bug#920047: glibc: CVE-2016-10739: getaddrinfo should reject IP addresses with trailing characters

* Salvatore Bonaccorso: > CVE-2016-10739[0]: > | In the GNU C Library (aka glibc or libc6) through 2.28, the getaddrinfo > | function would successfully parse a string that contained an IPv4 > | address followed by whitespace and arbitrary characters, which could > | lead applications to incorrect

Bug#923802: Acknowledgement (pthread: dead-lock while pthread_cond_destroy())

* Joël Krähemann: > This happens as you call pthread_cond_destroy() twice on the very same > cond variable. Surely that's an application bug. Why do you think this is a glibc issue? Thanks, Florian

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

* Laurent Bigonville: > Package: libc6-dev > Version: 2.28-8 > Severity: serious > > Hi, > > The crypt.3 manpage, state that _XOPEN_SOURCE should be define for > crypt() to be available. > > But it looks that it's currently the opposite, if _XOPEN_SOURCE is > defined, the function cannot be found.

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

* Laurent Bigonville: > Le 19/03/19 à 19:43, Florian Weimer a écrit : >> * Laurent Bigonville: >> >>> Package: libc6-dev >>> Version: 2.28-8 >>> Severity: serious >>> >>> Hi, >>> >>> The crypt.3 manpage, state that

Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

> About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. I believe the actual test failure is tst-pkey. Presumably, this rebuild was performed

Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)

* Christoph Berg: > with the update to glibc 2.28, collation aka sort ordering is > changing: > > $ echo $LANG > de_DE.utf8 > $ (echo 'a-a'; echo 'a a'; echo 'a+a'; echo 'aa') | sort > > stretch: > aa > a a > a-a > a+a > > buster: > a a > a+a > a-a > aa > > A vast number of locales

Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

* Lucas Nussbaum: > On 26/03/19 at 23:10 +0100, Aurelien Jarno wrote: >> On 2019-03-22 17:30, Florian Weimer wrote: >> > > About the archive rebuild: The rebuild was done on EC2 VM instances from >> > > Amazon Web Services, using a clean, minimal and up-to-date

Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

retitle 924891 glibc: misc/tst-pkey fails due to cleared PKRU register after signal in amd64 32-bit compat mode thanks * Lucas Nussbaum: > On 27/03/19 at 08:48 +0100, Florian Weimer wrote: >> > If that's useful, I can easily provide access to an AWS VM to debug this >> &

Options for 64-bit time_t support on 32-bit architectures

There is an effort under way to enhance glibc so that it can use the Y2038 support in the kernel. The result will be that more 32-bit architectures can use a 64-bit time_t. (Currently, it's x86-64 x32 only.) Originally, the plan was to support both ABIs in glibc for building new applications, si

Re: Options for 64-bit time_t support on 32-bit architectures

* Adrian Bunk: > [ only speaking for myself ] > > On Thu, Jul 18, 2019 at 11:05:53PM +0200, Florian Weimer wrote: >>... >> The consequence is that in order to build 32-bit-time_t libraries >> (Gtk, for example), an old glibc needs to be kept around. In >> practic

Re: Options for 64-bit time_t support on 32-bit architectures

* Adrian Bunk: > On Fri, Jul 19, 2019 at 07:13:28PM +0200, Florian Weimer wrote: >> * Adrian Bunk: >>... >> For comparison, the original plan was to provide a macro, perhaps >> -D_TIME_BITS=32 and -D_TIME_BITS=64, to select at build time which ABI >> set is used (

Re: Options for 64-bit time_t support on 32-bit architectures

* Simon McVittie: > On Fri, 19 Jul 2019 at 15:13:00 +0300, Adrian Bunk wrote: >> Remaining usecases of i386 will be old binaries, some old Linux binaries >> but especially old software (including many games) running in Wine. >> Old Linux binaries will still need the old 32bit time_t. > > Based on

Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

* Roman Savochenko: > Initial condition of the problem representing is a program in the > single source code, built on-and for Debian 7, 8, 9, 10 with a result > in the Live disks. I think glibc 2.13 as shipped by Debian was not built with --enable-experimental-malloc, so it doesn't use arenas.

Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

* Roman Savochenko: > Thanks you Florian, setting the environment MALLOC_ARENA_MAX=1 I have > got the memory effectivity some better even than in Debian 7! Is there a way to reproduce your results easily? Upstream, we're looking for workloads which are difficult to handle for glibc's malloc and

Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

* Roman Savochenko: >> Is there a way to reproduce your results easily? Upstream, we're >> looking for workloads which are difficult to handle for glibc's malloc >> and its default settings, so that we hopefully can improve things >> eventually. > > This way of the ready builds of the application

Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster

* Pavel Matěja: > The strange means they appear only on 2 servers out of 6. > Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon > E3-1220 v6 produced crashes. > It did not matter if the host Debian was Stretch or Buster. Do you see crashes on stretch as well? What does the

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

* Francesco Poli: > Hello everyone, > I am sorry to ask, but... I cannot understand what's the status of > [this bug report]. > > [this bug report]: > > A serious bug for libc6-dev without any apparent activity since last > March? Sure there must have been some hi

Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster

* Pavel Matěja: > Sorry for late answer. > > On 17. 08. 19 22:18, Florian Weimer wrote: >> * Pavel Matěja: >> >>> The strange means they appear only on 2 servers out of 6. >>> Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon >>

  1   2   >