Bug#351469: empty program triggers valgrind, too
: _dl_sysdep_start (in /lib/ld-2.7.so) ==22198==by 0x400230A: _dl_start (in /lib/ld-2.7.so) ==22198==by 0x4000A67: (within /lib/ld-2.7.so) ==22198== ==22198== Conditional jump or move depends on uninitialised value(s) ==22198==at 0x400B08F: _dl_relocate_object (in /lib/ld-2.7.so) ==22198==by 0x4003C16: dl_main (in /lib/ld-2.7.so) ==22198==by 0x4014837: _dl_sysdep_start (in /lib/ld-2.7.so) ==22198==by 0x400230A: _dl_start (in /lib/ld-2.7.so) ==22198==by 0x4000A67: (within /lib/ld-2.7.so) ==22198== ==22198== Conditional jump or move depends on uninitialised value(s) ==22198==at 0x400B09C: _dl_relocate_object (in /lib/ld-2.7.so) ==22198==by 0x4003C16: dl_main (in /lib/ld-2.7.so) ==22198==by 0x4014837: _dl_sysdep_start (in /lib/ld-2.7.so) ==22198==by 0x400230A: _dl_start (in /lib/ld-2.7.so) ==22198==by 0x4000A67: (within /lib/ld-2.7.so) ==22198== ==22198== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 0) ==22198== malloc/free: in use at exit: 0 bytes in 0 blocks. ==22198== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==22198== For counts of detected errors, rerun with: -v ==22198== All heap blocks were freed -- no leaks are possible. Maybe this is an amd64 issue only? Best regards Uwe -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (900, 'stable'), (300, 'testing-proposed-updates'), (300, 'testing'), (200, 'unstable'), (2, 'experimental'), (1, 'proposed-updates') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.22-3-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages libc6 depends on: ii libgcc1 1:4.2.2-3 GCC support library libc6 recommends no packages. -- debconf information: glibc/restart-failed: glibc/restart-services: -- Uwe Kleine-König, Software Engineer Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#534548: libc6: rt-tests FTBFS on sparc, s390, ia64 and hppa
clone 534548 -1 -2 retitle -1 libc6: rt-tests FTBFS on sparc, s390, ia64 tags -1 +patch retitle -2 libc6: please implement nptl on hppa block 534352 by -1 -2 thanks actually the hppa problem is a different one. hppa has the _tid member, but lacks some pthread things needed for rt-tests. According to Sebastian Andrzej Siewior sparc is already fixed in 2.10[1], and he also provided untested patches for s390 and ia64[2] Best regards Uwe [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=0001-sysdeps-unix-sysv-linux-sparc-bits-siginfo.h-struct-.patch;att=1;bug=534352 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=tid_fix_s390_ia64.patch;att=2;bug=534352 -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions| http://www.pengutronix.de/ | -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788799: libc6: pthread_cond_broadcast issue when surrounded by PTHREAD_PRIO_INHERIT mutex on ARM
Package: libc6 Version: 2.21-0experimental0 Severity: normal Tags: upstream fixed-upstream Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=18463 Hello, the attached program fails with an error on ARM platforms. (I only tested armhf, but I think armel is affected, too.) The problem is that pthread_mutex_unlock() in the main thread returns EPERM which it shouldn't. This only happens when using pthread_cond_broadcast, at least two threads and PTHREAD_PRIO_INHERIT. For more details refer to the upstream bug[1]. A possible solution documented in the upstream bug report is to pass --enable-kernel=3.15 (or something bigger). According to https://buildd.debian.org/status/fetch.php?pkg=glibcarch=armhfver=2.21-0experimental0stamp=1426842906 glibc is build using --enable-kernel=2.6.32, I guess that's from the setting MIN_KERNEL_SUPPORTED in debian/sysdeps/linux.mk. Given that stable has kernel 3.16 the probably easiest solution would be to bump the dependency to = 3.16?! Best regards Uwe [1] https://sourceware.org/bugzilla/show_bug.cgi?id=18463 -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 3.16.0-4-armmp (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libc6 depends on: ii libgcc1 1:4.9.2-10 libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.56 pn glibc-doc none ii locales2.21-0experimental0 -- debconf information excluded -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150615080703.834.97516.report...@crater.defre.kleine-koenig.org
Bug#854302: libc6: AI_ADDRCONFIG is not in all situations a useful default
Package: libc6
Version: 2.24-8
Severity: normal
Tags: upstream
Hello,
quoting getaddrinfo(3):
According to POSIX.1-2001, specifying hints as NULL should cause
ai_flags to be assumed as 0. The GNU C library instead assumes a value
of (AI_V4MAPPED | AI_ADDRCONFIG) for this case, since this value is
considered an improvement on the specification.
On an offline host trying to connect a service via 127.0.0.1 (or ::1)
should work. If however the application uses
getaddrinfo("127.0.0.1", "http", NULL, ...);
it fails to connect because of the above "improvement", while it would
just work if getaddrinfo implemented the POSIX specification.
(Note, currently this is not a problem because of a bug in
getaddrinfo(), see https://bugs.debian.org/854301.)
Best regards
Uwe
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (800, 'testing'), (600, 'unstable'), (500, 'testing-debug'),
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug#854301: libc6: getaddrinfo with AF_UNSPEC and AI_ADDRCONFIG should not return results on offline machine
Package: libc6
Version: 2.24-8
Severity: normal
Tags: upstream patch
Hello,
for ease of reproducibility I show my examples in Python, but I verified
that the problem is in glibc and not in Python:
On a machine without network access I get:
>>> import socket
>>> socket.getaddrinfo("0.0.0.0", "http", family=socket.AF_INET,
flags=socket.AI_ADDRCONFIG)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.5/socket.py", line 733, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto,
flags):
socket.gaierror: [Errno -2] Name or service not known
as expected. If however I use AF_UNSPEC instead of AF_INET I get:
>>> socket.getaddrinfo("0.0.0.0", "http", family=socket.AF_UNSPEC,
flags=socket.AI_ADDRCONFIG)
[(, , 6, '',
('0.0.0.0', 80))]
while it should fail in the same way as above instead.
Quoting getaddrinfo(3):
If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4
addresses are returned in the list pointed to by res only if the
local system has at least one IPv4 address configured [...].
The following patch should fix this:
--- a/sysdeps/posix/getaddrinfo.c
+++ b/sysdeps/posix/getaddrinfo.c
@@ -2351,7 +2351,8 @@
}
}
else if ((hints->ai_family == PF_INET && ! seen_ipv4)
- || (hints->ai_family == PF_INET6 && ! seen_ipv6))
+ || (hints->ai_family == PF_INET6 && ! seen_ipv6)
+ || (hints->ai_family == PF_UNSPEC))
{
/* We cannot possibly return a valid answer. */
__free_in6ai (in6ai);
Best regards
Uwe
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (800, 'testing'), (600, 'unstable'), (500, 'testing-debug'),
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug#780294: Attempts to resolve IPv6 even when only link-local IPv6 addresses configured
On Wed, Mar 11, 2015 at 10:59:40AM -0700, Josh Triplett wrote:
> Package: libc6
> Version: 2.19-15
> Severity: important
>
> I'm on a network that has somewhat broken DNS: attempts to resolve
> records for some hosts produce long timeouts.
>
> As I understand it, glibc is supposed to check whether the system has
> any non-link-local IPv6 addresses configured, and only attempt to
> resolve DNS requests to IPv6 addresses (via queries) if so.
I think this is a wrong understanding. The only function that I'm aware
to do something like that is getaddrinfo(3). If an application is still on
the older interface (gethostbyname(3) et al.) ipv6 stuff cannot be
suppressed AFAIK.
For getaddrinfo(3) this is only done when AI_ADDRCONF is passed in
hints->ai_flags.
You can easily see the differences using python:
>>> import socket
>>> def addrinfo(*args, **kwargs):
... for a in socket.getaddrinfo(*args, **kwargs):
... print(a)
...
>>> addrinfo("www.debian.org", "https", flags=socket.AI_ADDRCONFIG)
...
>>> addrinfo("www.debian.org", "https", flags=0)
...
(Note however that python's getaddrinfo has a different default when no
flags are given than glibc's getaddrinfo.)
I don't have access to an ipv4 only host with ipv6 ll addresses, but
maybe adding some more info here (Output of
ip a
ip -6 a
and the output of the above python sniplet) would be helpful.
Best regards
Uwe
signature.asc
Description: PGP signature
Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj
Hello, On Wed, Jun 27, 2018 at 08:03:00PM +, Niels Thykier wrote: > armel/armhf: > > > * Undesirable to keep the hardware running beyond 2020. armhf VM >support uncertain. (DSA) >- Source: [DSA Sprint report] > > [DSA Sprint report]: > https://lists.debian.org/debian-project/2018/02/msg4.html In this report Julien Cristau wrote: > In short, the hardware (development boards) we're currently using to > build armel and armhf packages aren't up to our standards, and we > really, really want them to go away when stretch goes EOL (expected in > 2020). We urge arm porters to find a way to build armhf packages in > VMs or chroots on server-class arm64 hardware. If the concerns are mostly about the hardware not being rackable, there is a rackable NAS by Netgear: https://www.netgear.com/business/products/storage/readynas/RN2120.aspx#tab-techspecs with an armhf cpu. Not sure if cpu speed (1.2 GHz) and available RAM (2 GiB) are good enough. The machine can run mainline Linux[1]. I think U-Boot doesn't support this machine in mainline though. Apart from that the people in #debian-arm (e.g. Sledge) seem to be positive that at least armhf should be fine to be built on arm64 hardware. Best regards Uwe [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts signature.asc Description: PGP signature
Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj
Hello Julien, On 06/29/2018 11:23 AM, Julien Cristau wrote: >> If the concerns are mostly about the hardware not being rackable, there >> is a rackable NAS by Netgear: >> >> >> https://www.netgear.com/business/products/storage/readynas/RN2120.aspx#tab-techspecs >> >> with an armhf cpu. Not sure if cpu speed (1.2 GHz) and available RAM (2 >> GiB) are good enough. The machine can run mainline Linux[1]. I think >> U-Boot doesn't support this machine in mainline though. >> > Rackable, while good, is only part of it. The main part is remote > management. I'm not seeing any mention of ipmi or anything like that in > the datasheet? you can access the serial console, but I don't think there is built-in support for something IPMI-like. > 2G is also way too little memory these days for a new buildd. Then the machine is out, the amount of RAM isn't upgradable. Best regards Uwe signature.asc Description: OpenPGP digital signature
