This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFC: tunables failure indications...


Re: https://sourceware.org/bugzilla/show_bug.cgi?id=25035
"sbrk() failure handled poorly in tunables_strdup"

The current failure mode for tunables is: if we can't allocate memory,
we delete the tunables env var and pretend it didn't exist, without
telling the user anything happened.

I think we should do better, but I don't know what.

IMHO tunables are "hints" but there should be *some* feedback when a
tunable can't be honored because of internal failures (vs tunables
that don't apply to the current arch, etc).

In the BZ noted above, where *sbrk* fails, I'm inclined to just
SIGSEGV because... well... *sbrk* just failed at the start of a
program.  Something has gone horribly wrong, even if the program
continues to run normally after that (it happens in our own testsuite
sometimes).

The helper functions in malloc return error codes for invalid values,
which the tunables harness completely ignores.  Not even a printf.

So... what is a reasonable thing for the user to expect, when a
tunable they specify cannot be honored?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]