Re: dash behaviour, was Re: core dump analysis

Hi Finn,

Am 09.04.2023 um 19:32 schrieb Finn Thain:
>> Looks like cat < /proc/self/maps | grep stack would give us enough
>> information without overwhelming the serial console?
>>
>> OTOH - if you can show the error is gone without stack address
>> randomization, that would be a hint maybe?
>>
>
> The results below were produced with 'norandmaps' added to the kernel
> parameters to avoid ASLR.
>
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
> root@debian:~# echo 3 > /proc/sys/vm/drop_caches
> [  913.560000] bash (1024): drop_caches: 3
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
> root@debian:~# sh /etc/init.d/mountdevsubfs.sh start
> *** stack smashing detected ***: terminated
> Aborted (core dumped)
> root@debian:~# sh -c "md5sum < /proc/self/maps"
> baacbaf944fb01d3200d924da7f7a815  -
> root@debian:~# sh -c "md5sum < /proc/self/maps"
> baacbaf944fb01d3200d924da7f7a815  -
> root@debian:~# sh -c "md5sum < /proc/self/maps"
> baacbaf944fb01d3200d924da7f7a815  -
> root@debian:~# sh -c "md5sum < /proc/self/maps"
> baacbaf944fb01d3200d924da7f7a815  -
> root@debian:~# sh -c "cat < /proc/self/maps"
> c0000000-c0021000 r-xp 00000000 08:06 38780      /usr/lib/m68k-linux-gnu/ld.so.1
> c0021000-c0023000 rw-p 00000000 00:00 0
> c0023000-c0024000 r--p 00021000 08:06 38780      /usr/lib/m68k-linux-gnu/ld.so.1
> c0024000-c0026000 rw-p 00022000 08:06 38780      /usr/lib/m68k-linux-gnu/ld.so.1
> c002a000-c0199000 r-xp 00000000 08:06 38786      /usr/lib/m68k-linux-gnu/libc.so.6
> c0199000-c019a000 ---p 0016f000 08:06 38786      /usr/lib/m68k-linux-gnu/libc.so.6
> c019a000-c019c000 r--p 00170000 08:06 38786      /usr/lib/m68k-linux-gnu/libc.so.6
> c019c000-c01a0000 rw-p 00172000 08:06 38786      /usr/lib/m68k-linux-gnu/libc.so.6
> c01a0000-c01aa000 rw-p 00000000 00:00 0
> d0000000-d0019000 r-xp 00000000 08:06 32713      /usr/bin/dash
> d001b000-d001c000 r--p 00019000 08:06 32713      /usr/bin/dash
> d001c000-d001d000 rw-p 0001a000 08:06 32713      /usr/bin/dash
> d001d000-d001f000 rwxp 00000000 00:00 0          [heap]
> d001f000-d0040000 rwxp 00000000 00:00 0          [heap]
> effdf000-f0000000 rw-p 00000000 00:00 0          [stack]
>
>
> So I guess this bug has more to do with timing and little to do with
> state, contrary to my guesswork above. And no doubt I will have to

What may still vary is physical mapping - I remember you had used some 
tool before to parse proc/<pid>/pagemap to determine the physical 
addresses for task stack areas? Or am I misremembering that from some 
other bug?

> contradict myself again if/when it turns out that uninitialized memory is
> a factor :-/

I haven't found a config option to initialize memory returned by the 
kernel page allocators, so not sure how to test that ...

Cheers,

	Michael