Re: dash behaviour, was Re: core dump analysis

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Finn,

Am 07.04.2023 um 16:03 schrieb Finn Thain:
>>> So, again, the best avenue I can think of for such experiments to
>>> modify the kernel to either keep track of the times of the wait4
>>> syscalls and
>>
>> The easiest way to do that is to log all wait and signal syscalls, as
>> well as process exit. That might alter timing if these log messages go
>> to the serial console though. Is that what you have in mind?
>>
>
> What I had in mind was collecting measurements in such way that would not
> impact timing, perhaps by storing them somewhere they could be retrieved
> from the process core dump.

Storing such information to the process core dump would need 
modifications to dash (allocate log buffer and pass the address to the 
kernel) in addition to the kernel. Taking Geert's suggestions to have 
the kernel allocate a log buffer (similar to the kernel message log) and 
read that out through procfs after the tests would be a lot easier.

>
> But that's probably not realistic and it's probably pointless anyway -- I
> don't expect to find an old bug in common code like kernel/exit.c, or in a
> hot path like those in arch/m68k/kernel/entry.S.
>
> More likely is that some kind of bug in dash causes it to corrupt its own
> stack when conditions are just right. I just need to figure out how to
> recreate those conditions. :-/
>
> When dash is feeling crashy, you can get results like this:
>
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh
> *** stack smashing detected ***: terminated
> Aborted (core dumped)
> Warning: mountdevsubfs should be called with the 'start' argument.
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh
> *** stack smashing detected ***: terminated
> Aborted (core dumped)
> Warning: mountdevsubfs should be called with the 'start' argument.
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh
> *** stack smashing detected ***: terminated
> Aborted (core dumped)
> Warning: mountdevsubfs should be called with the 'start' argument.
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh
> *** stack smashing detected ***: terminated
> Aborted (core dumped)
> Warning: mountdevsubfs should be called with the 'start' argument.
> root@debian:~#
>
> But when it's not feeling crashy, you can't:
>
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh
> Warning: mountdevsubfs should be called with the 'start' argument.
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh
> Warning: mountdevsubfs should be called with the 'start' argument.
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh
> Warning: mountdevsubfs should be called with the 'start' argument.
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh
> Warning: mountdevsubfs should be called with the 'start' argument.
>
> The only way I have found to alter dash's inclination to crash is to
> reboot. (I said previously I was unable to reproduce this in a single user
> mode shell but it turned out to be more subtle.)

I wonder what could change from one boot to another - can you have dash 
(and its subshells) dump /proc/self/maps and see whether there's any 
variation in that? But what we really need is the physical mappings. How 
can we find those?

With the kernel RNG disabled, I would expect neither of these mappings 
to change between boots?

Cheers,

	Michael