* sbrk() failure while processing tunables
@ 2021-11-01 16:54 Adhemerval Zanella
2021-11-01 17:17 ` Siddhesh Poyarekar
0 siblings, 1 reply; 6+ messages in thread
From: Adhemerval Zanella @ 2021-11-01 16:54 UTC (permalink / raw)
To: Libc-alpha, Carlos O'Donell, Siddhesh Poyarekar, DJ Delorie
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sbrk() failure while processing tunables
2021-11-01 16:54 sbrk() failure while processing tunables Adhemerval Zanella
@ 2021-11-01 17:17 ` Siddhesh Poyarekar
2021-11-02 19:56 ` Adhemerval Zanella
0 siblings, 1 reply; 6+ messages in thread
From: Siddhesh Poyarekar @ 2021-11-01 17:17 UTC (permalink / raw)
To: Adhemerval Zanella, Libc-alpha, Carlos O'Donell, DJ Delorie
On 11/1/21 22:24, Adhemerval Zanella wrote:
> 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.
Straight up mmap should be fine I think. AFAICT, we should have to
allocate exactly once, to copy the tunable string.
Thanks,
Siddhesh
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sbrk() failure while processing tunables
2021-11-01 17:17 ` Siddhesh Poyarekar
@ 2021-11-02 19:56 ` Adhemerval Zanella
2021-11-03 3:12 ` Siddhesh Poyarekar
0 siblings, 1 reply; 6+ messages in thread
From: Adhemerval Zanella @ 2021-11-02 19:56 UTC (permalink / raw)
To: Siddhesh Poyarekar, Libc-alpha, Carlos O'Donell, DJ Delorie
On 01/11/2021 14:17, Siddhesh Poyarekar wrote:
> On 11/1/21 22:24, Adhemerval Zanella wrote:
>> 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.
>
> Straight up mmap should be fine I think. AFAICT, we should have to allocate exactly once, to copy the tunable string.
Does it make sense to use rtld_malloc then to try optimize the allocation a bit?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sbrk() failure while processing tunables
2021-11-02 19:56 ` Adhemerval Zanella
@ 2021-11-03 3:12 ` Siddhesh Poyarekar
2021-11-03 3:15 ` DJ Delorie
0 siblings, 1 reply; 6+ messages in thread
From: Siddhesh Poyarekar @ 2021-11-03 3:12 UTC (permalink / raw)
To: Adhemerval Zanella, Libc-alpha, Carlos O'Donell, DJ Delorie
On 11/3/21 01:26, Adhemerval Zanella via Libc-alpha wrote:
>> Straight up mmap should be fine I think. AFAICT, we should have to allocate exactly once, to copy the tunable string.
>
> Does it make sense to use rtld_malloc then to try optimize the allocation a bit?
That'll work only for the dynamic case, you'll need special code for
static linking then. Alternatively, the rtld_malloc code looks
sufficiently independent that it could be split out into its own file
and included directly into dl-tunables.c.
Siddhesh
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sbrk() failure while processing tunables
2021-11-03 3:12 ` Siddhesh Poyarekar
@ 2021-11-03 3:15 ` DJ Delorie
2021-11-03 3:25 ` Siddhesh Poyarekar
0 siblings, 1 reply; 6+ messages in thread
From: DJ Delorie @ 2021-11-03 3:15 UTC (permalink / raw)
To: Siddhesh Poyarekar; +Cc: adhemerval.zanella, libc-alpha, carlos
Siddhesh Poyarekar <siddhesh@sourceware.org> writes:
> That'll work only for the dynamic case, you'll need special code for
> static linking then. Alternatively, the rtld_malloc code looks
> sufficiently independent that it could be split out into its own file
> and included directly into dl-tunables.c.
That implies that statically linked executables would have two
independent malloc implementations...
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sbrk() failure while processing tunables
2021-11-03 3:15 ` DJ Delorie
@ 2021-11-03 3:25 ` Siddhesh Poyarekar
0 siblings, 0 replies; 6+ messages in thread
From: Siddhesh Poyarekar @ 2021-11-03 3:25 UTC (permalink / raw)
To: DJ Delorie; +Cc: adhemerval.zanella, libc-alpha, carlos
On 11/3/21 08:45, DJ Delorie wrote:
> Siddhesh Poyarekar <siddhesh@sourceware.org> writes:
>> That'll work only for the dynamic case, you'll need special code for
>> static linking then. Alternatively, the rtld_malloc code looks
>> sufficiently independent that it could be split out into its own file
>> and included directly into dl-tunables.c.
>
> That implies that statically linked executables would have two
> independent malloc implementations...
Ahh no, not the full rtld_malloc implementation, I meant split out only
the rtld_malloc function (with the couple of static vars it depends on)
and call rtld_malloc() in dl-tunables instead of malloc(). The tunables
allocation is likely the first one and it doesn't need to be freed for
the lifetime of the process. Also, it cannot use the system malloc
since it sets up variables that control system malloc.
Siddhesh
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-11-03 3:25 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-01 16:54 sbrk() failure while processing tunables Adhemerval Zanella
2021-11-01 17:17 ` Siddhesh Poyarekar
2021-11-02 19:56 ` Adhemerval Zanella
2021-11-03 3:12 ` Siddhesh Poyarekar
2021-11-03 3:15 ` DJ Delorie
2021-11-03 3:25 ` Siddhesh Poyarekar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).