sbrk() failure while processing tunables

Adhemerval Zanella adhemerval.zanella@linaro.org
Mon Nov 1 16:54:56 GMT 2021


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.


More information about the Libc-alpha mailing list