This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Tests for res_init
On 06/03/2017 04:06 AM, H.J. Lu wrote:
> On Fri, Jun 2, 2017 at 1:43 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Fri, Jun 2, 2017 at 1:40 PM, Florian Weimer <fweimer@redhat.com> wrote:
>>> On 06/02/2017 10:19 PM, H.J. Lu wrote:
>>>> On Fri, Jun 2, 2017 at 6:49 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>>>> On 05/18/2017 10:05 PM, Siddhesh Poyarekar wrote:
>>>>>> Why not just have a tst-resolv-res_init.c and
>>>>>> tst-resolv-res_init-thread.c? That's how a lot of the other similar
>>>>>> kinds of tests are rewritten. I don't have a very strong opinion on
>>>>>> this though, you can choose the color of your shed :)
>>>>>
>>>>> I do it this way so that I can use #if instead of #ifdef, following the
>>>>> current guidelines to trigger -Wundef warnings on typos.
>>>>>
>>>>> I'm going to push this without the tests expecting incorrect results.
>>>>>
>>>>
>>>> On Fedora 25/x86-64, I got
>>>>
>>>> [hjl@gnu-6 build-x86_64-linux]$ cat resolv/tst-resolv-res_init.out
>>>> Timed out: killed the child process
>>>> [hjl@gnu-6 build-x86_64-linux]$ cat resolv/tst-resolv-res_init-thread.out
>>>> Timed out: killed the child process
>>>> [hjl@gnu-6 build-x86_64-linux]$
>>>
>>> I see that too, with 4.11.3-200.fc25.x86_64. What's your kernel version?
>>>
>>> I don't see the delay with 4.10.17-100.fc24.x86_64. There, the poll
>>> system calls return immediately. I wonder if it's some sort of
>>> regression in network namespaces.
>>
>> Yes, I am also running 4.11.3-200.fc25.x86_64.
>>
>
> I booted 4.10.16-200.fc25.x86_64 and the test passed. Any ideas?
I'm going to try to come up with a self-contained reproducer, and then
approach the kernel people if it still looks like a kernel bug.
Florian