Bug#897335: libc0.1-dev: Dev package exposes extattr_set_fd, extattr_get_fd, etc. system calls
Control: retitle -1 extattr prototypes declared in kernel headers sys/extattr.h but not implemented by libc0.1 Control: reassign -1 libc0.1,kfreebsd-kernel-headers On Tue, May 01, 2018 at 03:53:03PM +0200, Hilmar Preuße wrote: > Package: libc0.1-dev > Version: 2.27-3 > Severity: normal > > Dear Maintainer, > > I hope this is the right package to report on. > > I noticed that proftp v1.3.6 FTBFS on kfreebsd. James Clarke told me in > bug #897168 that libc0.1-dev exposes some system calls in header files, > which are not implement in any lib, hence the link stage fails. > > My impression is that functions, which do not exist should not be visible > in any header files. Consider to fix the header files. To clarify, kfreebsd-kernel-headers provides sys/extattr.h, which declare the BSD-ish extended attributes prototypes, but for which there is no corresponding implementation in libc0.1, not even stubs. Moreover, libc0.1-dev provides sys/xattr.h with the Linux-ish prototypes, but those are merely stubs in libc0.1 returning -1 with errno set to ENOSYS. It probably makes sense to use the BSD-ish ones given they are a slightly different interface and are OS-specific APIs, in which case libc0.1 should gain implementations for them, though alternatively the Linux-ish ones could be used and sys/extattr.h dropped for (non-libc) userspace. James
Bug#882874: glibc 2.25 FTBFS on ia64
[Cc'ing hppa people for reasons which will become clear] On Tue, Nov 28, 2017 at 08:22:56AM -0500, Jason Duerstock wrote: > Source: glibc > Followup-For: Bug #882874 > > This patch appears to correct the problem. > > -- System Information: > Debian Release: buster/sid > Architecture: ia64 > > Kernel: Linux 3.2.0-4-mckinley (SMP w/2 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > --- sysdeps/ia64/dl-machine.h > +++ sysdeps/ia64/dl-machine.h > @@ -45,7 +45,8 @@ > } > > #define ELF_MACHINE_BEFORE_RTLD_RELOC(dynamic_info) \ > - __ia64_init_bootstrap_fdesc_table (&bootstrap_map); > + __ia64_init_bootstrap_fdesc_table (&bootstrap_map); \ > + _dl_fptr_init(); > > /* Return nonzero iff ELF header is compatible with the running host. */ > static inline int __attribute__ ((unused)) As discussed on IRC with Jason, here are my findings for what on earth is going on here. This change is required due to the any/local-dlfptr.diff patch in Debian, which modifies elf/dl-fptr.c to introduce a _dl_fptr_init to assign local.root to &local.boot_table, with hppa calling this function early before it might have to process any relocations needing function pointers. Now, ignoring one important fact, this is needed on hppa for a very specific reason: it doesn't have special relative relocation types, instead reusing R_PARISC_DIR32 and others with symbol index 0, and doesn't set DT_RELACOUNT in its dynamic section (I assume because nobody bothered to implement it for bfd), so ld.so cannot perform any early relative relocations, despite having an implementation for elf_machine_rela_relative in sysdeps/hppa/dl-machine.h. This means that, depending on whether any function pointer-needing relocations appear before the R_hppa_DIR32 for local.root, local.root may not have been relocated, and thus cannot be used. Instead, the assignment is done manually in _dl_fptr_init using ELF_MACHINE_LOAD_ADDRESS to do this without needing any dynamic relocations to have been applied. However, hppa, at least currently, has its own sysdeps/hppa/dl-fptr.c, and does not compile elf/dl-fptr.c. This platform-specific dl-fptr.c also has the same workaround in it, so at least in the context of hppa, I don't see why this patch is needed any more (perhaps at one point elf/dl-fptr.c was being used for hppa on Debian, but it isn't now). Now, the only architecture actually using elf/dl-fptr.c currently is ia64. This patch therefore presents a problem, as its ELF_MACHINE_BEFORE_RTLD_RELOC does not call _dl_fptr_init (as pointed out by Jason's patch above). Thus, applying Jason's patch does in fact fix the issue on ia64. However, on ia64, there are specific relative relocations, and DT_RELACOUNT *does* get set to something sensible, so local.root gets relocated early, and this is why upstream glibc has not seen an issue with elf/dl-fptr.c on ia64. Therefore, this patch is *also* not needed on ia64 (albeit for different reasons), and so my suggested fix would be instead to simply drop this local patch, as its sole effect is to break ia64. Thoughts (especially from hppa people)? Regards, James
Bug#874074: ld.so: TLS relocations against local symbols don't work on powerpc, sparc and sparc64
Control: tags -1 fixed-upstream On Sat, Sep 02, 2017 at 07:22:23PM +0100, James Clarke wrote: > Package: libc6 > Version: 2.24-17 > Tags: upstream patch > Forwarded: https://sourceware.org/ml/libc-alpha/2017-09/msg00120.html > User: debian-sp...@lists.debian.org > Usertags: sparc sparc64 > User: debian-powe...@lists.debian.org > Usertags: powerpc > X-Debbugs-Cc: debian-sp...@lists.debian.org, debian-powe...@lists.debian.org > > Hi, > On the above architectures, TLS relocations against local symbols do not > work properly, crashing with SIGBUS or SIGSEGV on accessing the variable > in question. This is only a problem when using gold, as bfd will > optimise the relocations (since it knows the symbol cannot be pre-empted > by one in another object) to not refer to a symbol at all. I have > written a test script, available at [0]. > > The above patch has been tested on powerpc and sparc64 using my test > script, as well as on sparc64 using my local experimental GHC with > native code generation support, where the problem was first seen. > > Regards, > James > > [0] http://paste.debian.net/plain/984146 This has now been committed upstream[0] (although only to master, at least for now). Could you please include this in the next upload? Regards, James [0] https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=8644588807215ab09716ac04a150f91ac83acffd
Bug#874074: ld.so: TLS relocations against local symbols don't work on powerpc, sparc and sparc64
On 17 Sep 2017, at 20:55, Joe Nosay wrote: > > It no longer exists. Bah, it expired; recreated at http://paste.debian.net/986532/. Thanks, James > On Sat, Sep 2, 2017 at 2:22 PM, James Clarke wrote: >> Package: libc6 >> Version: 2.24-17 >> Tags: upstream patch >> Forwarded: https://sourceware.org/ml/libc-alpha/2017-09/msg00120.html >> User: debian-sp...@lists.debian.org >> Usertags: sparc sparc64 >> User: debian-powe...@lists.debian.org >> Usertags: powerpc >> X-Debbugs-Cc: debian-sp...@lists.debian.org, debian-powe...@lists.debian.org >> >> Hi, >> On the above architectures, TLS relocations against local symbols do not >> work properly, crashing with SIGBUS or SIGSEGV on accessing the variable >> in question. This is only a problem when using gold, as bfd will >> optimise the relocations (since it knows the symbol cannot be pre-empted >> by one in another object) to not refer to a symbol at all. I have >> written a test script, available at [0]. >> >> The above patch has been tested on powerpc and sparc64 using my test >> script, as well as on sparc64 using my local experimental GHC with >> native code generation support, where the problem was first seen. >> >> Regards, >> James >> >> [0] http://paste.debian.net/plain/984146 >> >> >
Bug#874074: ld.so: TLS relocations against local symbols don't work on powerpc, sparc and sparc64
Package: libc6 Version: 2.24-17 Tags: upstream patch Forwarded: https://sourceware.org/ml/libc-alpha/2017-09/msg00120.html User: debian-sp...@lists.debian.org Usertags: sparc sparc64 User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-Cc: debian-sp...@lists.debian.org, debian-powe...@lists.debian.org Hi, On the above architectures, TLS relocations against local symbols do not work properly, crashing with SIGBUS or SIGSEGV on accessing the variable in question. This is only a problem when using gold, as bfd will optimise the relocations (since it knows the symbol cannot be pre-empted by one in another object) to not refer to a symbol at all. I have written a test script, available at [0]. The above patch has been tested on powerpc and sparc64 using my test script, as well as on sparc64 using my local experimental GHC with native code generation support, where the problem was first seen. Regards, James [0] http://paste.debian.net/plain/984146
Bug#868076: libc6: gethostbyname assertion failure on m68k
Package: libc6
Version: 2.24-12
Tags: upstream patch
Forwarded: https://sourceware.org/ml/libc-alpha/2017-07/msg00466.html
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org
Hi,
On m68k, gethostbyname can sometimes cause an assertion failure:
> "nss_files/files-hosts.c:218: _nss_files_gethostbyname3_r: Assertion
> `(bufferend - (char *) 0) % sizeof (char *) == 0' failed."
This can be reproduced with the following simple program (though it may
depend on the exact system or chroot setup):
> #include
> #include
>
> int main(int argc, char **argv) {
> struct hostent *h = gethostbyname("localhost");
> printf("name: %s\n", h->h_name);
> return 0;
> }
This is because _nss_files_gethostbyname3_r asserts that bufferend is
sizeof-aligned (4 bytes for a char *), but parse_list only rounds to
__alignof__(char *), which is (unusually) just 2 bytes on m68k. The
above patch forwarded upstream weakens the assertion (and subsequent
rounding on future loop iterations) to only be __alignof__(char *).
Regards,
James
Re: Bug#856152: python-apt: FTBFS: Testsuite failure
Control: reassign -1 dirmngr 2.1.18-6 Control: retitle -1 dirmngr: Fails to resolve localhost and loopback addresses when only a loopback interface is available On Wed, Mar 01, 2017 at 01:31:40AM +0100, Julian Andres Klode wrote: > Control: severity 856152 important > > On Wed, Mar 01, 2017 at 06:39:37AM +0800, Chris Lamb wrote: > > retitle 856152 python-apt: FTBFS: AptKeyError: recv from > > 'hkp://localhost:19191' failed for > > '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553' > > thanks > > > > Julian Andres Klode wrote: > > > > > Retry it. Maybe it timed out or something. > > > > I don't think this is a timeout issue, but if it is, surely the package > > build should be a little more reliable? :) > > Well, it's some GPG issue, we can't figure out every GPG thing. > > This works fine with an up-to-date sid chroot in sbuild, so I don't > really care, or well, can't reproduce it. Seems more like a pbuilder > related issue. So the issue here is that, by default, pbuilder runs the build in a separate network namespace with only a loopback interface configured. The loopback interface works, you can bind and connect as normal (otherwise this would have been found a long time ago), but getaddrinfo has a slightly interesting deviation from POSIX. POSIX states[1]: > If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be > returned only if an IPv4 address is configured on the local system, > and IPv6 addresses shall be returned only if an IPv6 address is > configured on the local system. However, glibc's manpage states this: > 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, and IPv6 addresses are > returned only if the local system has at least one IPv6 address > configured. The loopback address is not considered for this case as > valid as a configured address. This flag is useful on, for example, > IPv4-only systems, to ensure that getaddrinfo() does not return IPv6 > socket addresses that would always fail in connect(2) or bind(2). Note that in fact glibc is in agreement with RFC 3493, which has the following modified version of POSIX's definition (thanks to Olly Betts for finding this): > If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be > returned only if an IPv4 address is configured on the local system, > and IPv6 addresses shall be returned only if an IPv6 address is > configured on the local system. The loopback address is not considered > for this case as valid as a configured address. Now, GPG is using getaddrinfo with AI_ADDRCONFIG[2]. I have yet to confirm that this is the issue here, but #853107 is a very similar bug, and removing the AI_ADDRCONFIG flag makes the build succeed. I don't know what the solution should be. Glibc's implementation seems sensible in the general case, but horribly broken when resolving localhost/127.0.0.1 with just a loopback interface up, which should be a perfectly valid thing to do. I believe that trying to build on a machine without a non-loopback interface up would also run into this bug, which is a rare situation these days, but not completely out of the question. In my opinion, glibc should not be ignoring the loopback address in this case, but I don't know whether that's easily possible in general and whether it would break existing programs. For pbuilder I guess we could work around it by bringing up a separate virtual interface, but I really don't like that idea, and it doesn't solve the problem of building on machines without a non-loopback interface. Here is a reproduction of the issue with plain GPG. I have a local SKS instance bound to 127.0.0.1:11371 which contains a single key. I had to kill dirmngr in between because it seems to cache lookups. > debian:~ james% ifconfig > eth0: flags=4163 mtu 1500 > inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255 > inet6 fe80::a00:27ff:fe01:add2 prefixlen 64 scopeid 0x20 > ether 08:00:27:01:ad:d2 txqueuelen 1000 (Ethernet) > RX packets 245463 bytes 341360397 (325.5 MiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 89176 bytes 5170918 (4.9 MiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > lo: flags=73 mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > inet6 ::1 prefixlen 128 scopeid 0x10 > loop txqueuelen 1 (Local Loopback) > RX packets 822 bytes 166056 (162.1 KiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 822 bytes 166056 (162.1 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Bug#792921: [sparc64] linking against libx264 crashes runtime linker
Control: reassign -1 binutils Control: retitle -1 ld on sparc64 converts R_SPARC_32 to R_SPARC_RELATIVE Control: affects -1 src:x264 Control: tags -1 upstream patch Control: forwarded -1 asdf On Tue, 21 Jul 2015 22:35:49 +0200 Andreas Cadhalpun wrote: > On 21.07.2015 21:44, Carlos O'Donell wrote: > > Does the problem always reproduce or just sometimes? > > Always. > > > If it's just sometimes then it's much much harder to figure out what's > > wrong. > > If it were just sometimes, I wouldn't have been able to trace it to libx264... > > > You'll need a dedicated person to track down exactly what is the > > concurrency issue and why it's failing. > > What I don't understand is why it only fails for libx264, but e.g. libx265 is > fine. > Also, I don't see how the code, where the crash happens, can possibly crash: > From do-rel.h [1]: > 85: const ElfW(Rel) *relative = r; > 86: r += nrelative; > [...] > 111:for (; relative < r; ++relative) > 112: DO_ELF_MACHINE_REL_RELATIVE (map, l_addr, relative); > > gdb claims it crashes at line 111. It does indeed crash there, although on line 112 not line 111. DO_ELF_MACHINE_REL_RELATIVE is defined to be elf_machine_rel_relative, which in this case has been defined to elf_machine_rela_relative, which is an always-inline function that will just perform some calculations and a single assignment to the relocation address. The reason it crashes is that libx264 has R_SPARC_RELATIVE relocations which are not 8-byte aligned. This is because ld incorrectly converts some R_SPARC_32 relocations into R_SPARC_RELATIVE ones, which is only valid for 32-bit Sparc. I have attached a patch which seems to fix this particular case; recompiling libx264, linking main.c with it and running the resulting main no longer leads to a bus error, and terminates with exit code 0. James signature.asc Description: PGP signature
Bug#816155: Assertion failure in gethostbyname
Package: libc6
Version: 2.21-9
User: debian-...@lists.debian.org
Usertags: m68k
Hi,
Backstory: I maintain polyml, and was porting it to m68k; when running the test
suite, I received an assertion failure in glibc in a call to gethostbyname.
It seems gethostbyname is broken, failing for me with
“nss_files/files-hosts.c:218: _nss_files_gethostbyname3_r: Assertion
`(bufferend - (char *) 0) % sizeof (char *) == 0' failed.” This can be
reproduced with the following simple program:
#include
#include
int main(int argc, char **argv) {
struct hostent *h = gethostbyname("localhost");
printf("name: %s\n", h->h_name);
return 0;
}
Delving inside glibc, _nss_files_gethostbyname3_r expects result->h_aliases to
be aligned to sizeof(char *), as can be seen in the assert (bufferend points to
an element in result->h_aliases, and each element is a char *). Provided this
is true when the function is called, it seems to correctly maintain the
invariant by rounding up bufferend when necessary.
However, the initial value of result->h_aliases is not aligned to sizeof(char
*). Instead, it is assigned in parse_list (nss_files/files-parse.c:245) and
aligned to __alignof__(char *). On many architectures, these are the same, but
on m68k, __alignof__(char *) == 2, but sizeof(char *) == 4. There may be
environments where result->h_aliases happens to be aligned to sizeof(char *) by
chance, but that is most certainly not the case on mine (latest unstable
running in ARAnyM).
I don’t know why bufferend is required to be aligned to sizeof(char *), and
believe that imposing __alignof__(char *) in _nss_files_gethostbyname3_r
instead would suffice. Alternatively, parse_list could choose MAX(sizeof(char
*), __alignof__(char *)) as the alignment. Either way, the implementation as a
whole is currently broken.
Regards,
James
signature.asc
Description: Message signed with OpenPGP using GPGMail
