On 2016-02-26 13:31, Carlos O'Donell wrote: > On Fri, Feb 26, 2016 at 7:46 AM, Fabian Niepelt <f.niep...@mittwald.de> 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 debian need to review those failures. They > indicate serious deviation from expected behaviour. At the very least > the bug 18665* tests should not fail. However, the tests are sensitive > to response order. > > -address: STREAM/TCP 10.0.3.6 80 > -address: STREAM/TCP 2001:db8::4:6 80 > +error: Name or service not known > > This is a weird failure.
The failures in this testsuite do not pass due to the patch we have that dynamically reloads /etc/resolv.conf when it changes. Just after the fake servers have been initialized, our libc reloads the configuration from /etc/resolv.conf, and thus the tests fail. Once removing the corresponding patch the tests pass, at least on my system. Anyway I don't think it's related to the problem reported here. The problem lies in the backport of the following patch, which is a prerequisite for fixing CVE-2015-7547. commit ab09bf616ad527b249aca5f2a4956fd526f0712f Author: Andreas Schwab <sch...@suse.de> Date: Tue Feb 18 10:57:25 2014 +0100 Properly fix memory leak in _nss_dns_gethostbyname4_r with big DNS answer Instead of trying to guess whether the second buffer needs to be freed set a flag at the place it is allocated This patch changes the ABI of the __libc_res_nsearch function, adding the ansp2_malloced argument. When this function is called by _nss_dns_gethostbyname4_r from a libc without the patch (ie the one installed before applying the security fix), the argument contains random values, leading to a segfault. IMHO making sure that programs are restarted after applying the security update should be enough, but I am not fully sure about my analysis, so a confirmation would be nice to have. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net