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.

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 po

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 thin

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

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

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

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

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 specifi

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 end

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

* 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

* 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 > > Y

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 be use

/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

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

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

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 >>

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

* 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 >> >

Re: Seeing clarification for locale names

* Marc Haber: > I would appreciate pointers to documentation, personal opinions, war > stories, encoding tales, historic lectures, anything that might > enlighten me and help me build the knowlegde and understanding about > UNIX locales are supposed to work in Debian GNU/Linux. Thank you in >

Bug#980764: libc6-dev: wrong return value for fputs when STDOUT_FILENO was closed()

* Morel Bérenger: >> * Bérenger: > ... >> Why do you think this is a bug? > > POSIX 10031-2017 standard says: POSIX requires that if you manipulate the underlying file descriptor of a stream, you first need to call fseek when using the stream again. Your example code does not do that, so

Bug#980764: libc6-dev: wrong return value for fputs when STDOUT_FILENO was closed()

* Bérenger: > When running following code: > > ```C > #include > #include > #include > > int main() > { > close( STDIN_FILENO ); > close( STDOUT_FILENO ); > int fd = dup( STDERR_FILENO ); > close( STDERR_FILENO ); > if( -1 == fprintf( stdout, "%d\n", fd ) ) >

Bug#976865: Fwd: Bug#974900: dash removes trailing slash from script arguments

* Herbert Xu: > On Thu, Dec 10, 2020 at 08:58:37AM +0100, Aurelien Jarno wrote: >> >> That's the dash symptoms. glob(3) takes a pattern and just returns the >> paths matching the pattern, as they are named on the filesystem. That >> said, the option GLOB_MARK can return a trailing slash for all

Bug#731082: Processed: severity of 731082 is normal

forwarded 731082 https://sourceware.org/bugzilla/show_bug.cgi?id=27008 tags 731082 + upstream thanks I happen to have a patch for this: A bit by accident, it ended up as part of the glibc-hwcaps work.

Bug#975026: Use 公元 not 西元

* 積丹尼 Dan Jacobson: > I think this, > $ LC_TIME=zh_TW.UTF-8 date > 西元2020年11月18日 (週三) 12時39分44秒 CST > should say 公元 not 西元. Why do you think so? These Taiwanese newspapers appear to use 西元 for Gregorian years:

Bug#972510: glibc: Please ignore misc/tst-sbrk and/or misc/tst-sbrk-pie on all archs

* Aurelien Jarno: > brk/sbrk is definitely something deprecated. But it is still part of the > API (especially for old architectures) and still used by software like > jemalloc, gcl or libgc. This is therefore important to keep this feature > in a good shape. > > It's also used by many less

Bug#969645: glibc: deferred error : (error "Deferred process exited abnormally:

* Aurelien DESBRIERES: > This is emacs and jedi-mode and much more elisp stuff to works with > emacs as python3 ide. > > Please update this glibc it seems to be outdated! That's simply not going to happen for the buster release. You will have to change the way you set up your pip environment.

Bug#969645: glibc: deferred error : (error "Deferred process exited abnormally:

* aurelien desbrieres: > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >try to use jedi-mode on emacs >* What exactly did you do (or not do) that was effective (or > ineffective)? >M-x jedi:install-server >

Bug#969618: getopt: optarg is NULL outside of loop

* John Scott: > #define _POSIX_C_SOURCE 200809L > #include > #include > #include > #include > int main(int argc, char *argv[]) { > int opt; > while((opt = getopt(argc, argv, "a:")) != -1) {} > assert(optarg != NULL); > } > > If this is invoked as './a.out -afoo', the inner

Bug#967938: libc6: systemd-sysusers SEGV due to glibc bug in fgetgsent

* Aurelien Jarno: > On 2020-08-06 06:08, Jinpu Wang wrote: >> Hi Florian, >> >> On Wed, Aug 5, 2020 at 6:44 PM Florian Weimer wrote: >> > >> > * Jinpu Wang: >> > >> > > Dear Maintainer: >> > > >> > > Sorry, a

Bug#967938: libc6: systemd-sysusers SEGV due to glibc bug in fgetgsent

* Jinpu Wang: > Dear Maintainer: > > Sorry, add some missing information below: > > After update to Buster, the systemd-sysusers are segfaulting every time. > After search around, I found following bugreport in glibc > https://sourceware.org/legacy-ml/libc-alpha/2016-06/msg01015.html > > I

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

* Florian Weimer: >> * Concern for mips, mips64el, mipsel and ppc64el: no upstream support >>in GCC >>(Raised by the GCC maintainer; carried over from stretch) > > I'm surprised to read this. ppc64el features prominently in the > toolchain work I do (thou

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

* Paul Gevers: > * Concern for armel and armhf: only secondary upstream support in GCC >(Raised by the GCC maintainer; carried over from stretch and buster) glibc upstream lately has trouble finding qualified persons to implement security fixes for the 32-bit Arm architecture. > * Concern

Re: [RFC PATCH v4 1/2] configure: Remove --enable-obsolete-nsl

* Petr Vorel: >> nss_compat no longer depends on libnsl in current glibc. It can be used >> without NIS, and some users do that. I don't think your patch changes >> this. > Interesting. I guess adding this would be worth then: > libnss_compat no longer depends on libnsl and can be used without

Re: [RFC PATCH v4 1/2] configure: Remove --enable-obsolete-nsl

* Petr Vorel: > Hi Florian, > > thank you for your review. I'll have time to send next version in second > half of July. If we merge new ports for glibc 2.32, it would be nice not include sunrpc in them. We'll figure something out. >> > diff --git a/grp/initgroups.c b/grp/initgroups.c >> >

Re: [RFC PATCH v4 1/2] configure: Remove --enable-obsolete-nsl

* Petr Vorel: > diff --git a/NEWS b/NEWS > index a660fc59a8..cfaf50c816 100644 > --- a/NEWS > +++ b/NEWS > @@ -33,6 +33,14 @@ Major new features: > > Deprecated and removed features, and other changes affecting compatibility: > > +* Remove configure option --enable-obsolete-nsl. libnsl is

Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename [and 1 more messages]

* Aurelien Jarno: >> This doesn't seem correct to me. Is there any documentation giving a >> rationale for this ? Is there a way to change this locally ? > > I do not know enough about apparmor and its threat model to know if it > should be considered or not. From the glibc point of view,

Re: [RFC PATCH v2 0/2] Remove --enable-obsolete-nsl --enable-obsolete-rpc

* Petr Vorel: >> I'm still having issues with elf/tst-ldconfig-ld_so_conf-update when >> running with both commits (it's ok when running only first commit). > > OK, I noticed core dump (can be reproduced): > systemd-coredump[26018]: Process 26016 (ld-linux-x86-64) of user 1000 dumped > core. > >

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Florian Weimer: > I raised the matter of compiler defaults on the GCC list: > > <https://gcc.gnu.org/pipermail/gcc/2020-April/232261.html> The link is now: <https://gcc.gnu.org/pipermail/gcc/2020-April/000491.html>

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

I raised the matter of compiler defaults on the GCC list: Thanks, Florian

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Noah Meyerhans: > On Sun, Apr 12, 2020 at 12:18:35PM +0200, Aurelien Jarno wrote: >> > Significant performance impact has also been observed in less contrived >> > cases (MariaDB and Postgres), but I don't have a repro to share. >> >> But indeed what counts is number on real workloads. It

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Noah Meyerhans: > On Sat, Apr 11, 2020 at 09:14:11PM +0200, Florian Weimer wrote: >> > At least if I'm reading the code right (which I may very well not be >> > doing, being generally unfamiliar with gcc internals), -mtune=generic >> > enables the equivalent of

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Noah Meyerhans: > On Sat, Apr 11, 2020 at 08:44:29AM +0200, Florian Weimer wrote: >> > Gcc provides two ways to enable support for these instructions at build >> > time. The simplest, and least disruptive, is to enable -moutline-atomics >> > globally in the arm64

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Noah Meyerhans: > Gcc provides two ways to enable support for these instructions at build > time. The simplest, and least disruptive, is to enable -moutline-atomics > globally in the arm64 glibc build. Shouldn't GCC do this by default, at least for -mtune=generic?

Bug#954715: glibc: FTBFS: tests failed: signal/tst-minsigstksz-1 signal/tst-minsigstksz-2

* Lucas Nussbaum: > Source: glibc > Version: 2.30-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200322 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. >> FAIL:

Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt

* Matthias Klose: > ok, now removing that leads to: > > $ cat foo.c > #include > > $ gcc -c foo.c > In file included from foo.c:1: > /usr/include/limits.h:124:26: error: no include path in which to search for > limits.h > 124 | # include_next > | ^ > >

Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt

* Matthias Klose: > On 3/4/20 9:33 AM, Florian Weimer wrote: >> * Matthias Klose: >> >>> The __glibc_has_include macro needs to be restored until GCC is rebuilt. At >>> least on s390x, you get a non-wrorking compiler, which at least cannot glibc >>&g

Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling

* Aurelien Jarno: >> I've been running into this myself a lot lately and wonder if >> anything has happened regarding this since 2014, after all it's >> been six years. >> I'm surprised so few people seem to be taking interest in this >> considering the amount of tools that rely on frame

Bug#951191: Backport /proc-based lchmod/fchmodat emulation

Unfortunately, this change tickles an XFS bug:

Bug#951191: Backport /proc-based lchmod/fchmodat emulation

consists of these patches: commit 173ec37bb2af6e30892a141d74d42db5957ddd36 Author: Florian Weimer Date: Sun Feb 9 11:50:44 2020 +0100 support: Add the xlstat function commit f6233ab412c3bebebacf65745e775e01506dd58d Author: Florian Weimer Date: Sun Feb 9 11:51:08 2020 +0100 Linux

Bug#948396: New glibc broke existing app due to historic stack alignment

* Petr Vandrovec: > Florian Weimer wrote on 1/7/2020 9:31 PM: >> * Petr Vandrovec: >> >>> As far as I can tell, while x86-64 ABI requires stack to be aligned >>> on entry to the functions, x86 ABI does not have any such >>> requirement, and so g

Bug#948396: New glibc broke existing app due to historic stack alignment

* Petr Vandrovec: > As far as I can tell, while x86-64 ABI requires stack to be aligned > on entry to the functions, x86 ABI does not have any such > requirement, and so glibc should align stack itself if it wants to > use XMM instructions that require aligned values. The i386 ABI was changed

Bug#941277: dispatch function missing in header file generated for RPC service

* Simon Richter: > while implementing an RPC service (in 2019, no less!) I found out that the > dispatch function generated by rpcgen is not listed in the generated header > file, so if the service is generated without a main function or inetd > interface, the code using it needs to create its

Bug#874160: Fedora has C.UTF-8

* Adam Borowski: > Looks like Fedora has C.UTF-8 now, and even backported this change to their > stable releases: > > https://bugzilla.redhat.com/show_bug.cgi?id=902094 > > They're not upstream, but a good part of distros that are not downstream > from Debian are downstream from Fedora. This

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 >

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

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#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

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: > 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.

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

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

* 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 >>

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,

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 >>

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

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

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

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 manp

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

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#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

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

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 it does not. >&g

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: 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#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 mean, but

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#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

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.

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

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:

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

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

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

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#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#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#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

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

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#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

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#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.

Bug#839280: libc6: asprintf(, "%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

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

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.

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 attached scr

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

* 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 >

  1   2   >