On Tue, 11 Apr 2023, Michael Schmitz wrote:
I was able to find some command line options (init_on_alloc,
init_on_free) and the related Kconfig symbols
(CONFIG_INIT_ON_ALLOC_DEFAULT_ON, CONFIG_INIT_ON_FREE_DEFAULT_ON).
Right - not sure how I managed to miss those.
init_on_free might delay the boot process a while! But I would guesss
init_on_alloc should be OK in the first instance.
Given the compiler supports -fzero-call-used-regs=used-gpr there's
also CONFIG_ZERO_CALL_USED_REGS. Also CONFIG_INIT_STACK_ALL_ZERO
(-ftrivial-auto-var-init=zero).
With all of those options enabled I still see dash crash sometimes. I
don't think I've learned anything new about the bug from that test.
The problem with these options is that they may produce a large effect
on the timing of events but they should still have no effect on the
behaviour of a correct userspace program.
Since we are dealing with a suspect userspace program, what could we
learn from such a test? E.g. if the crashing stopped one could simply
attribute
We don't know for definite that we deal with a suspect user space
program - it might just be a change in a previously fine program that
now exposes a subtle kernel bug (undetected for quite a long time, but
we've seen a few of those now...)?
That's right -- the kernel is also suspect. As is glibc. I will keep
looking for some way to narrow down the search.
