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.
