Re: Likely Bash bug

[Dennis Williamson]

On Tue, Mar 16, 2021, 6:19 PM Lawrence Velázquez <vq@larryv.me> wrote:

> > On Mar 16, 2021, at 6:01 PM, Jay via Bug reports for the GNU Bourne
> Again SHell <bug-bash@gnu.org> wrote:
> >
> >   Hello,
> >
> >   I have been using/exploring Linux for ~ 2yrs; have corrupted a couple
> >   systems more than once either through their instability with libraries
> >   or just excess stress.
> >
> >   I don't consider current case to be either of the above; see attached.
> >
> >   The system is modern Intel computer, 2018 to 2019 configured in BIOS
> >   mode. Operating system is BionicPup64 8.0.
> >
> >   Best Regards.
> > <Bash-issue.rtf>
>
> Reproduced below for anyone who doesn't feel like reading a bug
> report out of an RTF document.
>
> vq
>
>
>
> From: root
> To: bug-bash@gnu.org,bash@packages.debian.org
> Subject: [ash--bash interference (for reference)]
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
> -DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time
> -D_FORTIFY_SOURCE=2 -g -O2
> -fdebug-prefix-map=/build/bash-vEMnMR/bash-4.4.18=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wall
> -Wno-parentheses -Wno-format-security
> uname output: Linux puppypc23046 4.19.23 #1 SMP Tue Feb 19 15:07:58 GMT
> 2019 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 4.4
> Patch Level: 19
> Release Status: release
>
> Description:
>         [Original ash executable/script reduced to 4 bytes after download
> of "Clonezilla"
> through Puppy Package Manager. Reboot of system hung at
> 'switching-layers'.]
>
> Repeat-By:
>         [Believed occurred after an ash co-dependency download as part of
> install.]
>
> Fix:
>         [Noted xwin errors relating to ash on shutdown; had backup
> savefile. Compared /bin and saw the difference. Replaced ash from backup
> file to working folder.]
>


I've been playing with your optimized code changing the read to grab data
in chunks like some of the other optimized code does - thus extending your
move from by-word to by-line reading to reading a specified larger number
of characters.

IFS= read -r -N 4096 var

And appending the result of a regular read to end at a newline. This seemed
to cut about 20% off the time. But I get different counts than your code.
I've tried using read without specifying a variable and using the resulting
$REPLY to preserve whitespace but the counts still didn't match.

In any case this points to larger chunks being more efficient.

>