From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 26AFD3857433 for ; Wed, 4 Aug 2021 20:12:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 26AFD3857433 Received: by mail-pj1-x1032.google.com with SMTP id dw2-20020a17090b0942b0290177cb475142so10483477pjb.2 for ; Wed, 04 Aug 2021 13:12:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lWA9jLSU3Vg1cB5wiqpqEu4wu8h96rkWIXqZFKNK7gE=; b=s26T+JdZ9kaPlTjq2YKEO3XeQCAJaacyvsapv7KunXU+StWJddytz4fbVm7RpEOK1U vvjrjwUCAcMG9kMN//ISVqEArJsSN+go/mlMY9knvsBEhmShaSDh8W9Qv6ERDp3tkWp3 rNTJlBPLLKYY4fFH0XNmP2pgKpJDQ1KmS3ye3bMJXsAhV9nVODRaeykff7FnCbPORBoa SJ/seaQwqXrg8AFeyWsxs3B4g5OJH9zDAZf2t2lEbAO+mY3Y/M0HNSuMNABiY6h+lbiA ldnFXrQAlPYNYNDdEJoh7yHuY7HnyiRryt/ErX/8ADOVzopakDvFZ9xWa4Xx8gKNX8Q4 t37w== X-Gm-Message-State: AOAM5328q4JkbFyPSgoIHj6FywB/C4ABJ8tRj4bpf6ZZf77UpfWOPdOU prErNsiLP264uw5Ubb9OP3hQVQ== X-Google-Smtp-Source: ABdhPJxlXwDsn1NGRW+bcK0DmLdiUXJKVM+b+gjLvOVsu7xbnDKgZge1p4GvaweDvTduNK0d2AwIgw== X-Received: by 2002:a63:1614:: with SMTP id w20mr94833pgl.198.1628107966153; Wed, 04 Aug 2021 13:12:46 -0700 (PDT) Received: from ?IPv6:2804:431:c7ca:76cd:ebc7:4201:855e:55a1? ([2804:431:c7ca:76cd:ebc7:4201:855e:55a1]) by smtp.gmail.com with ESMTPSA id m17sm3837824pfh.133.2021.08.04.13.12.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Aug 2021 13:12:45 -0700 (PDT) Subject: Re: glibc 2.34 failed tests To: Michael Brunnbauer Cc: libc-help@sourceware.org, Siddhesh Poyarekar References: From: Adhemerval Zanella Message-ID: <33440979-bdc9-5e77-f090-8b61c27f03cc@linaro.org> Date: Wed, 4 Aug 2021 17:12:42 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2021 20:12:48 -0000 On 04/08/2021 09:29, Michael Brunnbauer wrote: > > hi > > On Wed, Aug 04, 2021 at 08:56:17AM -0300, Adhemerval Zanella wrote: >>> FAIL: elf/tst-dlopenfail >> >> This is a new failure, could you post the .out output? >> >>> FAIL: malloc/tst-safe-linking > > Those two failures occured with glibc 2.33 but not with 2.34 on my current > machine. > >>> FAIL: malloc/tst-tcfree2 >> >> This is another new failure., could you post the .out output as well? > > FAIL: tcache double free > Expected signal 'Aborted' from child, got none > >>> FAIL: nss/tst-nss-files-hosts-multi >>> FAIL: resolv/tst-bug18665 >>> FAIL: resolv/tst-resolv-search >> >> I recall this might fail depending of how the system network is configured. >> What .out file shows? > > It's an ipv4 only system. Here are the outputs: > > cat nss/tst-nss-files-hosts-multi.out > Timed out: killed the child process > Termination time: 2021-08-03T15:50:02.888711343 > Last write to standard output: 2021-08-03T15:49:22.870384035 > > cat resolv/tst-bug18665.out > warning: unshare (CLONE_NEWUTS) failed: Invalid argument > warning: could not enter network namespace > Timed out: killed the child process > Termination time: 2021-08-03T15:48:22.269459412 > Last write to standard output: 2021-08-03T15:48:02.250298068 > > cat resolv/tst-resolv-search.out > warning: unshare (CLONE_NEWUTS) failed: Invalid argument > warning: could not enter network namespace > Timed out: killed the child process > Termination time: 2021-08-03T15:48:52.829291960 > Last write to standard output: 2021-08-03T15:48:32.810330616 This is due the missing kernel support for network namespace, I think we should set the tests as unsupported in this case. > > >>> cat ./rt/tst-mqueue10.out >>> error: tst-mqueue10.c:46: not true: q != (mqd_t) -1 >>> error: 1 test failures >> >> I think this might be related to the fact rt/tst-mqueue10.c uses the >> "/tst-mqueue2-" as template (it might interfere with rt/tst-mqueue2.c >> itself). > > I opened a ticket for this one: https://sourceware.org/bugzilla/show_bug.cgi?id=28188 Thanks, but the only reason I see to this fail is if the kernel misses POSIX message queue support. Could you check if your kernel has CONFIG_POSIX_MQUEUE enabled? > >>> cat ./time/tst-itimer.out >>> tst-itimer.c:76: numeric comparison failure (widths 64 and 32) >>> left: 10000 (0x2710); from: it_old.it_interval.tv_usec >>> right: 20 (0x14); from: 20 >>> tst-itimer.c:90: numeric comparison failure >>> left: 20 (0x14); from: it.it_interval.tv_usec >>> right: 10000 (0x2710); from: it_old.it_interval.tv_usec >>> tst-itimer.c:118: numeric comparison failure >>> left: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec >>> right: 8589934591 (0x1ffffffff); from: 0x1ffffffffull >>> tst-itimer.c:119: numeric comparison failure (widths 64 and 32) >>> left: 0 (0x0); from: it_old.it_interval.tv_usec >>> right: 20 (0x14); from: 20 >>> tst-itimer.c:141: numeric comparison failure >>> left: 8589934591 (0x1ffffffff); from: it.it_interval.tv_sec >>> right: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec >>> tst-itimer.c:142: numeric comparison failure >>> left: 20 (0x14); from: it.it_interval.tv_usec >>> right: 0 (0x0); from: it_old.it_interval.tv_usec >>> tst-itimer.c:76: numeric comparison failure (widths 64 and 32) >>> left: 10000 (0x2710); from: it_old.it_interval.tv_usec >>> right: 20 (0x14); from: 20 >>> tst-itimer.c:90: numeric comparison failure >>> left: 20 (0x14); from: it.it_interval.tv_usec >>> right: 10000 (0x2710); from: it_old.it_interval.tv_usec >>> tst-itimer.c:118: numeric comparison failure >>> left: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec >>> right: 8589934591 (0x1ffffffff); from: 0x1ffffffffull >>> tst-itimer.c:119: numeric comparison failure (widths 64 and 32) >>> left: 0 (0x0); from: it_old.it_interval.tv_usec >>> right: 20 (0x14); from: 20 >>> tst-itimer.c:141: numeric comparison failure >>> left: 8589934591 (0x1ffffffff); from: it.it_interval.tv_sec >>> right: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec >>> tst-itimer.c:142: numeric comparison failure >>> left: 20 (0x14); from: it.it_interval.tv_usec >>> right: 0 (0x0); from: it_old.it_interval.tv_usec >>> error: 12 test failures >> >> I almost sure this is the same issue I saw on an older kernel under KVM [1] >> >> [1] https://patchwork.sourceware.org/project/glibc/patch/20210719163846.2954193-3-adhemerval.zanella@linaro.org/ > > My machine is not a virtual one though. Here is the ticket for this one: > > https://sourceware.org/bugzilla/show_bug.cgi?id=28189 Thanks, but I do not think KVM is the only thing that changes the clock precision here.