[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Likely Bash bug
Re: Likely Bash bug
Tue, 16 Mar 2021 22:08:17 -0500
On Tue, Mar 16, 2021, 6:19 PM Lawrence Velázquez <email@example.com> wrote:
> > On Mar 16, 2021, at 6:01 PM, Jay via Bug reports for the GNU Bourne
> Again SHell <firstname.lastname@example.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.
> From: root
> To: email@example.com,firstname.lastname@example.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
> -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
> [Original ash executable/script reduced to 4 bytes after download
> of "Clonezilla"
> through Puppy Package Manager. Reboot of system hung at
> [Believed occurred after an ash co-dependency download as part of
> [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
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.