From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id 3A25A3858001 for ; Mon, 1 Nov 2021 16:55:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3A25A3858001 Received: by mail-oi1-x235.google.com with SMTP id w193so25852014oie.1 for ; Mon, 01 Nov 2021 09:55:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject:content-transfer-encoding; bh=eiNrflQqC6Zff+wdlAy88K/gc8525QVGNcSGXpyiMHk=; b=ygOJrFQ4/fkddaCNH1g/IpQ7L9ctCyeEObtw7xT7/cE29HBeE5vLPil3naweIJMijn UwBQtHGjjEPUnXVmiXP4+T2N1H6RF9dwmbd1FQvWY8DXC1mk1LkmJGXBaKoO7dIZJhIk oKJGtdGMz1zaCRlx5xgXOnf3M3lR/T3lG75L0NpCOi+ZHp2d9v28qoXMSZHqxHtgGMva 3SNhRiiqkM61CiHCx+uOC8bdx38fc+6bk6gv11QZUpEA7d717eh+/iFxZNfBPJCewvOL BZ7axMQ/paq7hXw/k+mIZfhQeQqzrX0TLlrdl61279I03zjEsXGj6fdtVs0NkRynjGkp n/wA== X-Gm-Message-State: AOAM53094wt30XACwff86JvpYyCTj32g5KsCrpo1BzyUlqSTDGNRTuKI q0IUUZWbAW6CBzE2MaZHmVunCXHN4T3fpg== X-Google-Smtp-Source: ABdhPJwP1Kq1oFCa0W7NJjqEWYxq6qr5MOPVUCy3pyMMqPydzAxNECihXl3ISX8n5FL2ECI51iB0Gw== X-Received: by 2002:a05:6808:2307:: with SMTP id bn7mr135417oib.32.1635785699525; Mon, 01 Nov 2021 09:54:59 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:b64f:7c54:165f:8728:a193? ([2804:431:c7cb:b64f:7c54:165f:8728:a193]) by smtp.gmail.com with ESMTPSA id g127sm4298633oia.3.2021.11.01.09.54.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Nov 2021 09:54:59 -0700 (PDT) Message-ID: Date: Mon, 1 Nov 2021 13:54:56 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Content-Language: en-US To: Libc-alpha , Carlos O'Donell , Siddhesh Poyarekar , DJ Delorie From: Adhemerval Zanella Subject: sbrk() failure while processing tunables Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable 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-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 16:55:02 -0000 On powerpc64le I am seeing sporadic elf/tst-dso-ordering9 failures due: /bin/sh /home/azanella/glibc/build/powerpc64le-linux-gnu/elf/tst-dso-ordering9-dir/tst-dso-ordering9.sh /home/azanella/glibc/build/powerpc64le-linux-gnu/ ' env' 'GCONV_PATH=/home/azanella/glibc/build/powerpc64le-linux-gnu/iconvdata LOCPATH=/home/azanella/glibc/build/powerpc64le-linux-gnu/localedata LC_ALL=C' > /home/azanella/glibc/build/powerpc64le-linux-gnu/elf/tst-dso-ordering9.out; ../scripts/evaluate-test.sh elf/tst-dso-ordering9 $? false false > /home/azanella/glibc/build/powerpc64le-linux-gnu/elf/tst-dso-ordering9.test-result sbrk() failure while processing tunables sbrk() failure while processing tunables sbrk() failure while processing tunables sbrk() failure while processing tunables make[2]: Leaving directory '/home/azanella/glibc/glibc-git/elf' FAIL: elf/tst-dso-ordering9 original exit status 1 FAIL: tst-dso-ordering9_20-aebdc(GLIBC_TUNABLES=glibc.rtld.dynamic_sort=1) execution test FAIL: tst-dso-ordering9_30-baedc(GLIBC_TUNABLES=glibc.rtld.dynamic_sort=1) execution test FAIL: tst-dso-ordering9_86-dcaeb(GLIBC_TUNABLES=glibc.rtld.dynamic_sort=2) execution test FAIL: tst-dso-ordering9_112-ecbda(GLIBC_TUNABLES=glibc.rtld.dynamic_sort=2) execution test I haven't debug in the resulting mapping, but it does looks like something related to ASLR since successive 'make test t=elf/tst-dso-ordering9' shows different subtests failures (tst-dso-ordering9_XXXX). And the issue seems that tunables_strdup() does calls srbk() to allocate the new string. On a059f9505bbef1 we changed to return a _dl_fatal_printf since BZ#25035 states that in practice no setting a tunable should not prevent the process start. I commented it with Carlos on the weekly call and he brought that he has discussed it internally. My question is there something preventing us to provide a mmap() allocator similar to the one used by rtld_malloc to used along with tunables? I think using an explicit allocator disjointed from rtld_malloc (since it might free blocks either in default or error path) should provide a more robust tunables experience.